I don't have to get things working again when TypeScript's Node ecosystem delivers major version bumps, in exchange for fancier features and security enhancements. (This is not an anti-security statement).
It's not that the language would break something, though it may, it's more that different parts of the ecosystem surrounding the language will shift at different rates. Some people will follow SemVer some people will not.
The number of modules and packages being installed in today's projects is astronomical. It's a lot of work to keep everything in sync. I would love to get real stastistics on time-cost of library incompatibilities for the Node.js universe.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I like your demo of compo-sable JavaScript objects but....
No upgrade in any language (including JavaScript) should be done with reading the breaking changes section.
No upgrade in any language (including JavaScript) should be done with reading the breaking changes section.
Both these arguments are User errors.
Yes, I do agree in principle. But it's not always that simple: github.com/Microsoft/TypeScript/is...
It's not that the language would break something, though it may, it's more that different parts of the ecosystem surrounding the language will shift at different rates. Some people will follow SemVer some people will not.
The number of modules and packages being installed in today's projects is astronomical. It's a lot of work to keep everything in sync. I would love to get real stastistics on time-cost of library incompatibilities for the Node.js universe.