Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade dependencies! #1029

Closed
tropicalraisel opened this issue Aug 30, 2021 · 10 comments · Fixed by #1033
Closed

Upgrade dependencies! #1029

tropicalraisel opened this issue Aug 30, 2021 · 10 comments · Fixed by #1033

Comments

@tropicalraisel
Copy link

Listing by npm-check-updates:

 @babel/plugin-proposal-class-properties                                   ^7.0.0  →   ^7.14.5
 @babel/plugin-transform-react-jsx                                         ^7.0.0  →   ^7.14.9
 @babel/preset-react                                                       ^7.0.0  →   ^7.14.5
 @babel/preset-typescript                                                  ^7.0.0  →   ^7.15.0
 @symfony/stimulus-bridge                                        ^1.1.0 || ^2.0.0  →    ^2.1.0
 @vue/babel-helper-vue-jsx-merge-props                                     ^1.0.0  →    ^1.2.1
 @vue/babel-preset-jsx                                                     ^1.0.0  →    ^1.2.4
 @vue/compiler-sfc                                                         ^3.0.2  →    ^3.2.6
 autoprefixer                                                             ^10.2.0  →   ^10.3.3
 babel-eslint                                                             ^10.0.1  →   ^10.1.0
 chai                                                                      ^4.2.0  →    ^4.3.4
 core-js                                                                   ^3.0.0  →   ^3.16.4
 eslint                                                          ^6.7.0 || ^7.0.0  →   ^7.32.0
 eslint-loader                                                             ^4.0.0  →    ^4.0.2
 eslint-plugin-header                                                      ^3.0.0  →    ^3.1.1
 eslint-plugin-import                                                      ^2.8.0  →   ^2.24.2
 file-loader                                                               ^6.0.0  →    ^6.2.0
 fork-ts-checker-webpack-plugin                                  ^5.0.0 || ^6.0.0  →    ^6.3.2
 fs-extra                                                                  ^9.0.0  →   ^10.0.0
 handlebars-loader                                                         ^1.7.0  →    ^1.7.1
 http-server                                                              ^0.12.3  →   ^13.0.1
 less                                                                      ^4.0.0  →    ^4.1.1
 less-loader                                           ^7.0.0 || ^8.0.0 || ^9.0.0  →   ^10.0.1
 mocha                                                                     ^8.2.1  →    ^9.1.1
 postcss                                                                   ^8.1.0  →    ^8.3.6
 postcss-loader                                                  ^4.0.0 || ^5.0.0  →    ^6.1.1
 preact                                                         ^8.2.1 || ^10.0.0  →  ^10.5.14
 preact-compat                                                            ^3.17.0  →   ^3.19.0
 sass                                                                     ^1.17.0  →   ^1.38.2
 sass-loader                              ^9.0.1 || ^10.0.0 || ^11.0.0 || ^12.0.0  →   ^12.1.0
 sinon                                                                     ^9.0.2  →   ^11.1.2
 strip-ansi                                                                ^6.0.0  →    ^7.0.0
 stylus                                                                   ^0.54.5  →   ^0.54.8
 stylus-loader                                         ^3.0.2 || ^4.0.0 || ^5.0.0  →    ^6.1.0
 ts-loader                                                       ^8.0.1 || ^9.0.0  →    ^9.2.5
 typescript                                                               >=3.6.3  →   >=4.4.2
 vue-template-compiler                                                       ^2.5  →      ^2.6
 webpack-notifier                                                          ^1.6.0  →   ^1.13.0
 @babel/core                                                               ^7.7.0  →   ^7.15.0
 @babel/plugin-syntax-dynamic-import                                       ^7.0.0  →    ^7.8.3
 @babel/preset-env                                                        ^7.10.0  →   ^7.15.0
 assets-webpack-plugin                                                      7.0.*  →     7.1.*
 chalk                                                                     ^4.0.0  →    ^4.1.2
 css-loader                                                                ^5.2.4  →    ^6.2.0
 css-minimizer-webpack-plugin                                              ^2.0.0  →    ^3.0.2
 mini-css-extract-plugin                                                   ^1.5.0  →    ^2.2.0
 pretty-error                                                              ^3.0.3  →    ^3.0.4
 resolve-url-loader                                                        ^3.1.2  →    ^4.0.0
 semver                                                                    ^7.3.2  →    ^7.3.5
 style-loader                                                              ^2.0.0  →    ^3.2.1
 terser-webpack-plugin                                                     ^5.1.1  →    ^5.1.4
 webpack                                                                    ^5.35  →     ^5.51
 webpack-dev-server                                                 ^4.0.0-beta.0  →    ^4.0.0
 yargs-parser                                                             ^20.2.4  →   ^20.2.9
@jkabat
Copy link

jkabat commented Aug 31, 2021

There are again problems with stable release of webpack-dev-server ^4.0.0.

@Kocal
Copy link
Member

Kocal commented Aug 31, 2021

Hi, a lot of our prod and dev dependencies (webpack loaders, plugins, ...) can not be updated because we want to ensure Webpack Encore works with lowest and highest dependencies versions (see CI).

However, I think you can upgrade those dependencies without any problems:

  • chai
  • http-server
  • mocha
  • sinon
  • strip-ansi
  • chalk
  • pretty-error (not sure)
  • yargs-parser

@tropicalraisel
Copy link
Author

@Kocal To that point then, why not create a separate project called something like "webpack-encore-edge" that supports newer dependencies? That way there would be less burden on developers that are trying to use plugins that use the same dependencies.

@tropicalraisel
Copy link
Author

@jkabat What are those problems?

@weaverryan
Copy link
Member

Many of these are not actually a problem. But yes, there are several that we do need to update :). There are already various PR's for them - I'll merge them soon - I've been on vacation and dealing with some family issues.

@Kocal
Copy link
Member

Kocal commented Aug 31, 2021

@Kocal To that point then, why not create a separate project called something like "webpack-encore-edge" that supports newer dependencies? That way there would be less burden on developers that are trying to use plugins that use the same dependencies.

@tropicalraisel do you mean a package containing dependencies without any versions constraints? It can be dangerous and will for sure increase the time and difficulty such a package, aside the "official" Webpack Encore.

If you want dev/prod dependencies update, the better is to create pull requests. If it's not merged yet, simply use your fork temporarily.

@tropicalraisel
Copy link
Author

@Kocal I mean having a "bleeding edge" version of Webpack Encore to experiment with newer packages. This way a contributor team can focus on the current package, and another can focus on updating. This puts less pressure on various individuals to maintain the project by having to review and test if everything works with the base package. Once the "bleeding edge" is stable, it becomes a proper release and the teams shift again. It would help straggling developers along with legacy issues too.

This is just speculation. Having really enjoyed using this project alongside Webpack 5, I'm hoping to see it continue to progress and not grow stale.

@jrushlow
Copy link
Contributor

jrushlow commented Aug 31, 2021

@Kocal I mean having a "bleeding edge" version of Webpack Encore to experiment with newer packages. This way a contributor team can focus on the current package, and another can focus on updating. This puts less pressure on various individuals to maintain the project by having to review and test if everything works with the base package. Once the "bleeding edge" is stable, it becomes a proper release and the teams shift again. It would help straggling developers along with legacy issues too.

This is just speculation. Having really enjoyed using this project alongside Webpack 5, I'm hoping to see it continue to progress and not grow stale.

Doing as you describe would add unneeded complexity to the maintenance of the library and would more than likely break Symfony's Stability Promise sooner or later. As @Kocal suggested, if a user needs bleeding edge packages, it would be better for them to fork the repository and adjust the constraints for their use case.

I'm not in favor of this approach.

@tropicalraisel
Copy link
Author

@Kocal I mean having a "bleeding edge" version of Webpack Encore to experiment with newer packages. This way a contributor team can focus on the current package, and another can focus on updating. This puts less pressure on various individuals to maintain the project by having to review and test if everything works with the base package. Once the "bleeding edge" is stable, it becomes a proper release and the teams shift again. It would help straggling developers along with legacy issues too.
This is just speculation. Having really enjoyed using this project alongside Webpack 5, I'm hoping to see it continue to progress and not grow stale.

Doing as you describe would add unneeded complexity to the maintenance of the library and would more than likely break Symfony's Stability Promise sooner or later. As @Kocal suggested, if a user needs bleeding edge packages, it would be better for them to fork the repository and adjust the constraints for their use case.

I'm not in favor of this approach.

Could there then be a guide provided to help users do this if it's needed? The only barrier to entry using this approach is simply how to use it.

@jkabat
Copy link

jkabat commented Aug 31, 2021

@jkabat What are those problems?

#1017 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants