Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem with stuff like introducing .env support out the box is breaking backwards compatibility in a silent way, ie without any code changes and in a way that'd still run the same in dev, and pass tests on CI etc, and then just affect prod.

I know this shouldn't ever happen, but you can well imagine plenty of legacy/badly configured setups where it would. More pertinently, where it would no matter how loudly you warn about it in release notes etc.

When you're as mature and used a platform as node, you just can't risk things like this, unfortunately, no matter how more convenient it would be for the vast majority of users.



That would be very easily solved by adding a Node.js version or range in your package.json that specifies where the program is supposed to run, and treat major versions as breaking. There's a balance to be had here, and avoiding breaking anything at all costs is surely not really balanced and it's starting to add a lot of cruft that will be needed to be maintained long-term.

The solution is not to "warn loudly" here; specify a Node.js version in your package.json, and your code will continue working on that version. Upgrade the Node.js engine version, and then it's on the person upgrading making sure that nothing breaks. That's how virtually all platforms work (except the web itself, but that's not "versioned" so it's fair).

It's a bit more troublesome when changing core packages and considering dependencies, but the same could apply there.


Apple breaks stuff all the time when updating their APIs. If you hold yourself to decisions made long in the past, then your platform will undoubtably become crusty and stale. Maybe Node maintainers are ok with that, but it shouldn’t be surprising when people go to greener pastures.


I do agree to an extent but the specific point I'm making here is about breaking things in a potentially silent, not obvious way.

Not sure what things you are referencing here in terms of Apple's breaking API changes but if it's the sort of breaking change where previous code just doesn't compile or run on the new version it's a different matter in my view - as in, it's something far easier to catch in dev or testing and not only affect prod.


Node already has a solution for this: core modules are prefixed with "node:" to distinguish them from third-party modules. https://fusebit.io/blog/node-18-prefix-only-modules/?utm_sou...




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: