-
-
Notifications
You must be signed in to change notification settings - Fork 199
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
Comments
There are again problems with stable release of webpack-dev-server ^4.0.0. |
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:
|
@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. |
@jkabat What are those problems? |
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. |
@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. |
@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. |
|
Listing by
npm-check-updates
:The text was updated successfully, but these errors were encountered: