81–90 of 101 posts
Earlier quoted context omitted.
> And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old. We have recurring Jira tickets for updating npm dependencies every two weeks. One developer is occupied between half a day and two days because the amount of breakage in the npm ecosystem is enormous. It’s ridiculous and sucks the life out of us.
Why not just use fixed versions and upgrade when you have a reason to?
It's telling that most instructions deal with the Javascript toolchain and not Rails itself. And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old. I'm looking forward to Phoenix 1.6 which ditches Webpack for esbuild. Every step away from the insane churn of the modern frontend world is welcome.
For the record, next Rails version (v7) is on the path of ditching webpack, too.
Earlier quoted context omitted.
> And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old. We have recurring Jira tickets for updating npm dependencies every two weeks. One developer is occupied between half a day and two days because the amount of breakage in the npm ecosystem is enormous. It’s ridiculous and sucks the life out of us.
I sincerely do not understand this complaint. Do you dislike bug fixes and new features? Would you be happier with a stagnant tooling ecosystem?
It's telling that most instructions deal with the Javascript toolchain and not Rails itself. And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old. I'm looking forward to Phoenix 1.6 which ditches Webpack for esbuild. Every step away from the insane churn of the modern frontend world is welcome.
> And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old. We have recurring Jira tickets for updating npm dependencies every two weeks. One developer is occupied between half a day and two days because the amount of breakage in the npm ecosystem is enormous. It’s ridiculous and sucks the life out of us.
I still have a few projects running Webpack 1 without issue.
Earlier quoted context omitted.
> And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old. We have recurring Jira tickets for updating npm dependencies every two weeks. One developer is occupied between half a day and two days because the amount of breakage in the npm ecosystem is enormous. It’s ridiculous and sucks the life out of us.
In curious why you feel the need to do that? I typically only update dependencies either for serious security issues or new features I really, really want to use. I still have a few projects running Webpack 1 without issue.
Earlier quoted context omitted.
I sincerely do not understand this complaint. Do you dislike bug fixes and new features? Would you be happier with a stagnant tooling ecosystem?
Sadly it’s the constant barrage of breaking changes. It’s not just a version number bump and everything keeps running. Patch version breaks the app. Minor version breaks the app. Major version breaks the app (understandable in semver) but multiple inter-dependencies need to be updated in parallel.
For instance, Webpack 5 deprecated worker-loader in favor of a construction using new URL() and import.meta.url. Adopting this was a huge pain, but what we get in exchange is a system that can load workers using standard syntactic constructions that work under e.g. our test runner or in a NodeJS microservice. Something like that is worth the hassle to me.
As for minor and patch versions causing breaking changes, this has happened to me a few times. Terser Webpack Plugin 3.0.6 exposed flaws in a custom Webpack plugin we'd written for internal use, which I cannot fairly blame on anybody but ourselves. Babel 7.5 broke CommonJS targets in a way that wasn't fixed until 7.6, which was truly unpleasant and something I hope to never deal with again. TypeScript doesn't use Semver and usually has breaking changes in every point release. For the most part, however, semver has proven trustworthy.
The Darwinian foment that characterizes the front-end ecosystem has created the best tools I've ever used. When I look at the quality of tooling available on stacks that prioritize stability, I am not jealous.
Earlier quoted context omitted.
Why not just use fixed versions and upgrade when you have a reason to?
That sounds like a nightmare waiting to happen. You have a package which hasn't been upgraded by your team for two years and suddenly someone finds a vulnerability in every version before 3.xyz.something. When you check, your version package is 1.3.5. Now you have to upgrade multiple major versions, and in all likelihood the package had transitive dependencies which have had many updates themselves as well. After sev…
Earlier quoted context omitted.
> I'm looking forward to Phoenix 1.6 which ditches Webpack for esbuild. Every step away from the insane churn of the modern frontend world is welcome. I don't like the churn either, but ditching X for Y only contributes to the churn.
Looks like Rails wants off Webpacker as well https://github.com/rails/importmap-rails
Earlier quoted context omitted.
For the record, next Rails version (v7) is on the path of ditching webpack, too.
What? It was just integrated as default. Do you have a source/link for more information?
"Unless new evidence comes to bear that refutes the basic tenets of this analysis, Rails 7.0 will aim to give you a default setup based on import maps, and leave the Webpacker approach as an optional alternative."