Re:Rome: An experimental JavaScript toolchain
by protonimitate on Monday April 13, 2020 @01:39PM
(#22857992)
I like the idea of simplifying the tool chain, but I'm curious how flexible Rome will be in terms of settings/customization.
Like, if it "replaces webpack", am I locked into Rome's idea of what an "optimal bundler config" looks like? If I need more from a bundler, do I have to completely replace Rome with the "old" toolchain? How extendible is Rome on its own?
I'm wondering if it will have something like CRA's "eject" that allows you to override the defaults, without having to replace entire portions of it.
Real problems this causes:
1. security surface area. Running npm audit in many large projects is going to give you scary results. And that's just the known advisories.
2. 3rd-party support. How many of the 1000+ packages you've ended up pulling into your node_modules will continue to be actively maintained throughout the life of your project, what stability pains will dead subdependencies cause, and what will the long-term maintenance cost of rooting them out (and finding equivalent replacements) be? Will it cause forced deprecation of features in your app?
So with all the above, low-dependency/no-dependency projects are attractive. Many go to extreme and repeat the old mistakes of NiH. Rome seems to me to be this extreme kneejerk (and liable to some serious lock-in).
The sensible thing here is moderation: just choose dependencies carefully.