3 ms·

> and not run into a single problem? I didn't say not a single problem: I said "its fine, nothing bad happens, it works". Of course there are issues, and bugs,

> and not run into a single problem? I didn't say not a single problem: I said "its fine, nothing bad happens, it works". Of course there are issues, and bugs, some of them due to dependencies breaking, but nothing calamitous or actually bad, and nothing out of the ordinary compared to other stacks and tools imo. Npm module churn can be annoying sure, but on the flip side its good to be getting incremental patch updates sometimes too. And with exact versions in package.json and shrinkwrap you can eliminate enough uncertainty that to all intents and purposes its really not a problem. > dumped the entire Gulp ecosystem Amen to that. Gulp plugin eco-system has been messed up for a year or more. We do all our frontend builds with npm scripts now, running the bare cli tools where possible, and reducing dependencies as much as possible (e.g. Gulp and all its plugins).

Silhouette 11y ago
I suppose we just have different amounts of tolerance for unexpected breakage. It sounds like we do have a similar philosophy as far as tooling goes: simple scripts, minimal dependencies. But I add to that a strong preference for tools like build systems and package managers and source control systems to have completely deterministic behaviour and therefore provide reproducible results by default. In practice, trusting semver has caused real world problems for some projects I've worked on with non-dev dependencies too. For example, a few weeks ago, Facebook pushed a bad update to React that completely broke dev builds on IE. It was fixed a few days later, but during that window NPM considered the broken version just as good as the version we'd been developing and testing with for the past couple of weeks. Tracking that one down wasted a few hours in our office as we tried to figure out why tests were failing on our new build/CI machine but whenever the developers tried it everything seemed to be working fine. I guess I just don't understand the decision to make ambiguity the default with NPM, particularly with the Node/NPM culture of using very many small dependencies. It's not as if it's difficult to issue a message if a newer version of something relevant is available, or to provide a command or option to deliberately change to newer versions of packages -- pretty much every package manager in every language I've ever used does these things -- so introducing unnecessary variability just seems like asking for trouble.

Silhouette 11y ago

I suppose we just have different amounts of tolerance for unexpected breakage. It sounds like we do have a similar philosophy as far as tooling goes: simple scripts, minimal dependencies. But I add to that a strong preference for tools like build systems and package managers and source control systems to have completely deterministic behaviour and therefore provide reproducible results by default. In practice, trusting semver has caused real world problems for some projects I've worked on with non-dev dependencies too. For example, a few weeks ago, Facebook pushed a bad update to React that completely broke dev builds on IE. It was fixed a few days later, but during that window NPM considered the broken version just as good as the version we'd been developing and testing with for the past couple of weeks. Tracking that one down wasted a few hours in our office as we tried to figure out why tests were failing on our new build/CI machine but whenever the developers tried it everything seemed to be working fine. I guess I just don't understand the decision to make ambiguity the default with NPM, particularly with the Node/NPM culture of using very many small dependencies. It's not as if it's difficult to issue a message if a newer version of something relevant is available, or to provide a command or option to deliberately change to newer versions of packages -- pretty much every package manager in every language I've ever used does these things -- so introducing unnecessary variability just seems like asking for trouble.