3 ms·
tl;dr blindly upgrading 100s of dependencies didn’t work out. But, is this instability due to the ecosystem, or the choices of the developer? I work on a large
by jitl 5y ago
tl;dr blindly upgrading 100s of dependencies didn’t work out. But, is this instability due to the ecosystem, or the choices of the developer?
I work on a large, highly interactive web app that does a lot of the fancy stuff like code push to native apps, offline caching, heavy use of browser storage, real time collaboration. Our stack is React, Express, Typescript, built with Webpack. Every year or so we upgrade one of these major components, like Webpack, which does take a week, following a semver major migration guide, but usually nets us some performance and developer productivity wins. I’m sure if I tried to upgraded all our dependencies at once, it’d explode. So, we don’t do that.
Maybe I sound like a C developer arguing “C unsafety is fine, just don’t make mistakes”. There’s a ton of hype around JS libraries — of course there’s bigger hype waves in this ecosystem given its population and ease of publishing (compare to Java where you need to open a JIRA ticket to publish to maven central) but it’s a personal choice to follow fads like installing this ChakraUI thing or to use boring tools that you already know work.
- eatonphil 5y agoYours sounds like a reasonable practice, I do the same thing myself. I agree that it's up to the developer to make things easier on him/herself or to bring in unneeded dependencies or complicate the build process.