Open jonkoops opened 4 years ago
Regarding security fixes, I don't consider it a big problem, because Node.js is not used during runtime, only during build time. The attack surface is much smaller. And because of the way the plugin uses caching (I mean, how it's written currently), it wouldn't auto-update to later LTS versions automatically, it would always use the oldest one that satisfies the major version number. So a simple change in the plugin would make the situation worse, not better. I'm sure it would be possible to change the logic, but it would take some work.
I've never ever experienced working on a project where Webpack/Rollup etc. have actually required constant version bumps of the LTS, I think it's a YAGNI feature. I do, however, have experience with annoying regressions that ruined the build process, which is why the decision to prioritize reproducibility was made in the first place.
If you've bumped the Node/npm version a considerable number of times in your pom.xml files (out of necessity, and not just for the sake of always being on the latest version), and that's a real problem, then I would suggest not using the frontend-maven-plugin at all; but instead use Node Version Manager combined with exec-maven-plugin.
I also don't agree with this idea - people should control which version they are using - Node has a looong history of things randomly breaking - backward compatibility is not their greatest strength :D I imagine you could always write yourself a small script that would check the latest LTS and update the POM file - wrap it up in a CI job - and here you go :)
This issue is a continuation of https://github.com/eirslett/frontend-maven-plugin/issues/641.
I would like to request it to made possible for versions tags such as
latest-v0.12.x
orlatest-erbium
to be specified. This would be to allow LTS versions of NodeJS to be tracked without having to manually update the version number.The motivation for this request is simple, LTS versions of Node are guaranteed for some time to receive important bug fixes and security fixes whilst guaranteeing to not introduce any breaking changes. Although the chance that a regression might be introduced does exist I would consider it to be very small given patches for LTS versions of Node are hand-picked.
I believe that the user should at least be given the choice to track a version range as they might want to get security and bug-fixes straight away, whilst teams that focus on reproducibility can still continue to use a fixed version. Furthermore it is good to acknowledge that there is already a lot of tooling out there which provides access to Node versioning in this manner including but not limited to NPM, Docker and Node Version Manager.