Live data from Hacker News

Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js

victorbjelkholm.github.io

41–50 of 69 posts

Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js

#41
post #5

Frankly, I feel like this is an indictment of all software development, everywhere. When you need to do this kind of a thing, you are doing it wrong. I do not mean I am doing it any better, I have the same issues e.g. working on Android, but there are probably some fundamental things we could be doing to avoid all these horrible symptoms. Things like NixOS come to mind, where people are actively researching and exper…

Wouldnt the only solution to "see if you code worked with changing apis" to either 1) never change apis even if you were wrong or you have more opportunities or 2) know everything beforehand and implement the api perfect

also 3) have enough time to implement all the features after having this magic insight. A lot of people take for granted that successful software makes tough choices to ship

Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js

#43
post #7

Earlier quoted context omitted.

What do you recommend for how we could do it better?

Take a look outside of the node.js micro cosmos.

Python has a great tool called Tox for testing on multiple python versions: https://tox.readthedocs.org/en/latest/

Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js

#44
Have you thought of running this as a service? Would be nice to just through an NPM module at it and make sure it will run across multiple versions. Without having to install docker, etc. Not sure I'd pay for it, but maybe somebody would...

Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js

#45

Earlier quoted context omitted.

Then just write es5. It'll still run everywhere forever.

That's my plan. But it means I can't use other people's modules anymore.

Why? Put a transpiler inside your build chain.

Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js

#46

Earlier quoted context omitted.

There are actually 303 versions of node (including iojs, according to the Node Version Manager): $ nvm ls-remote | wc -l 303 Most of those are patch releases. There are 47 minor releases and 6 major releases: $ nvm ls-remote | grep -oE 'v\d+\.\d+' | uniq | wc -l 47 $ nvm ls-remote | grep -oE 'v\d+' | uniq | wc -l 6 Most language implementations probably have similar number of releases.

yeah -- perhaps there's a lot of negative things to be said about node, but the fact that they've released multiple versions? really? https://clojure.org/community/downloads_older http://www.scala-lang.org/download/all.html https://www.python.org/downloads/ etc...

I don't think the issue is that they've released multiple versions, it's more that they've had so many backward-incompatible releases.

Python and OCaml have had 3 each. Libc has had 6. 32 for something that's been around less than a decade is a bit excessive.

Are all these 32 actually backwards-incompatible?

Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js

#47

Earlier quoted context omitted.

There are actually 303 versions of node (including iojs, according to the Node Version Manager): $ nvm ls-remote | wc -l 303 Most of those are patch releases. There are 47 minor releases and 6 major releases: $ nvm ls-remote | grep -oE 'v\d+\.\d+' | uniq | wc -l 47 $ nvm ls-remote | grep -oE 'v\d+' | uniq | wc -l 6 Most language implementations probably have similar number of releases.

yeah -- perhaps there's a lot of negative things to be said about node, but the fact that they've released multiple versions? really? https://clojure.org/community/downloads_older http://www.scala-lang.org/download/all.html https://www.python.org/downloads/ etc...

[deleted]

Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js

#48

Earlier quoted context omitted.

yeah -- perhaps there's a lot of negative things to be said about node, but the fact that they've released multiple versions? really? https://clojure.org/community/downloads_older http://www.scala-lang.org/download/all.html https://www.python.org/downloads/ etc...

I don't think the issue is that they've released multiple versions, it's more that they've had so many backward-incompatible releases. Python and OCaml have had 3 each. Libc has had 6. 32 for something that's been around less than a decade is a bit excessive. Are all these 32 actually backwards-incompatible?

They're not strictly backward incompatible: one should ideally only have to test across the major versions (nodejs is currently on major version 5, though that's not strictly reflective given the fork to iojs, and the change in versioning system on merge back)

Testing across all 32 (or 303) versions is still going to be useful for catching bugs and quirks between minor versions (as opposed to deliberate, documented breaking API changes)

Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js

#49

Earlier quoted context omitted.

yeah -- perhaps there's a lot of negative things to be said about node, but the fact that they've released multiple versions? really? https://clojure.org/community/downloads_older http://www.scala-lang.org/download/all.html https://www.python.org/downloads/ etc...

I don't think the issue is that they've released multiple versions, it's more that they've had so many backward-incompatible releases. Python and OCaml have had 3 each. Libc has had 6. 32 for something that's been around less than a decade is a bit excessive. Are all these 32 actually backwards-incompatible?

>Are all these 32 actually backwards-incompatible?

Node uses semantic versioning [0] and the current release is 5.10.z

The breaking changes can be found here [1] By searching for `SEMVER-MAJOR`. Some seem rather unavoidable for progress (updating dependencies...) and some are for things that have been deprecated. I'm not an expert but it looks like there are several security related changes as well?

In my eyes a backwards incompatible change that breaks a feature that has been deprecated for years or is insecure is a change worth making. Stability is bad if it means remaining insecure.

[0] http://semver.org/

[1] https://github.com/nodejs/node/blob/v5.10.1/CHANGELOG.md

Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js

#50
post #25

Dumb question, from someone who doesn't work with Node.js: Why are there 32 versions of it?

Node.js has that 60's free love nudist colony experiment feel.

Except that everyone is crazy and high off the fumes of DIY

...actually that does sound pretty 60s

Post reply on HN