node.js versions support

[ai]

@hzoo what versions we should support? node.js only. Or we should add io.js?

Do we have any open database for version to not update browerslist on every node.js release?

Maybe we could create is? Do we know somebody from node.js release team to integrate a process (yeap, I a big optimiste :D)?

[chicoxyzzy]

nvm has nvm ls-remote command which lists available versions to install. I'm guessing we can dive into nvm's source code and use similar way to get versions.

[ai]

@chicoxyzzy good idea! Do you want to investigate more?

I afraid that we couldn’t do HTTP request on user side. But maybe we could pack answer in some JSON and publish it on npm.

[chicoxyzzy]

But maybe we could pack answer in some JSON and publish it on npm.

Yep. That was the idea. We can even add preversion npm script to generate new JSON file, then automatically add it to git and push a commit. So every new release will have latest versions list at the moment of that release (we can also use git hooks via https://github.com/typicode/husky instead of preversion but it is an implementation detail)

I'll do some research and provide a PR soon but no guarantees on estimates :)

[ai]

Cool idea. But I thought node-releases.

What if we will made a major update and some of enterprise users could not update for it for a months. But they need a fresh database.

I have this problem in Autoprefixer. Enterprise users afraid to update code, but could be OK with updating data-only npm packages.

Do you want to start this npm package? Or I could use http://cultofmartians.com/ to find a maintainer.

[chicoxyzzy]

I'll do it

[ai]

@chicoxyzzy awesome. You have great contribute and I could be sure with package maintaining :).

[chicoxyzzy]

Just created very naïve implementation https://github.com/chicoxyzzy/node-releases

Ideally I need to

• add a bot which will poll Node.js website every couple hours (serve it on Heroku?)
• bot will create a PR using GitHub API in case if there is a diff in files (similar to how greenkeeper.io creates PRs)
• add some collaborators

So release process will be automated and in the same time humans will be able to prevent broken PRs if bot will go crazy 🤖

[ai]

@chicoxyzzy Awesome!

We may need:

1. Is version is supported right now. They have a information on https://github.com/nodejs/LTS, but not in machine-friendly format. Should we ask them for better format?
2. Could we built a extra version with only version, lts and future supported keys? I afraid that Autoprefixer become even bigger in browser version.

@hzoo what node queries do we want for Babel? My suggestions:

• node >= 7
• latest 2 node versions
• supported node (if it is easy to implement by @chicoxyzzy)

[chicoxyzzy]

1. It's easy to calculate End Of Support dates. I can add this info.
2. Hmm... yes I think so. We can use https://github.com/lerna/lerna to create separate npm packages (with raw data and preprocessed data for browserlist)

As for supported node I think browserlist can use calculated End Of Support mentioned in point 1 above

[ai]

@chicoxyzzy no need for separated npm package. You could put releases-light.json

ALso, what do you think to join iojs and node to one file? Browserslist code will be more easy.

[ai]

@chicoxyzzy good idea to put support time calculation to Browserlist. I need a support duration for every version.

[iamstarkov]

@ai

what node queries do we want for Babel?

my 2 cents. pls, make it possible to make it easy to query two latest + all lts, maybe last 2 version, lts

[iamstarkov]

btw, why do you want to separate iojs and node? iojs is basically 1.0 ≤ node < 4.0

[chicoxyzzy]

@iamstarkov technically iojs never was a node. It's a fork and almost all enterprise companies ignored it. So it may be useful for someone to separate iojs and nodejs

[iamstarkov]

@chicoxyzzy thats correct, though as far iojs happened quite a while ago, nobody will query it intentionally. so separation probably is just an implementation detail

[chicoxyzzy]

compat-table and babel-preset-env could query it

[chicoxyzzy]

@ai just realised end dates for versions are not useful at all. What we need is end of support dates for minors / majors (depending on major version of node — 0 or bigger). Actually I'm not sure we need to keep this data in node-releases repo. We need to decide what results should queries return. For example let's take a query mentioned by @iamstarkov:

last 2 versions, lts

should it return ['6.9.1', '6.9.0'] or ['6.9.1', '4.6.2']?

It seems like latter is more correct.
Same for next query:

last 2 versions

It feels like it should return ['7.1.0', '6.9.1'].
We also should consider that v6.9.x is LTS but v6.8.1 is not. IMO patch version is pretty useless for us (and we shouldn't keep them in processed data) but both major and minor are significant.

Anyway I updated the repo and we can start experiment with processed data https://github.com/chicoxyzzy/node-releases

[ai]

@chicoxyzzy sure, great question :).

1. I think lts is bad query. It refers to all LTS releases :). Should we replace it to supported node versions (but it is too long)?
2. I agree that last 2 versions should returns ['7.1.0', '6.9.1']. But I think we should replace browser’s last 2 versions to some more clear. last 2 node majors?
3. Also we should keep in mind Chakra and other non-v8 engines ;).

[ai]

Maybe we should rename package to js-cli-releases? But it is not CLI. browserless-js-releases? How it called correctly? :D

[chicoxyzzy]

1. IMO lts is a nice to have. Someone really might want to query only versions which were LTS. It's kinda similar to firefox esr query which is supported by browserlist
2. Yep. We should consider how to differ node and iojs and how to query both.
3. AFAIK Chakra is not officially supported and nodejs team has no any plans to maintain Chakra builds so there are only custom builds from Microsoft.

Maybe we should rename package to js-cli-releases? But it is not CLI. browserless-js-releases? How it called correctly? :D

Personally I like node-releases name 😟

@hzoo would be great if you chime in. Do you have any opinion on how browserlist queries for node should be designed? Also do we need patch versions or major.minor is enough?

---

@ai we definitely should grab @ChALkeR and @vkurchatkin on HolyJS conf to discuss this in person! 😉🍺

[ai]

1. OK, node lts will be current supported LTS releases (like firefox esr selects only latest ESR).
2. I think we should think about node like “node and iojs”. Nobody will care about that iojs past. We should not make thing complicated.
3. I mean not only node-chakra. But do we have other non-v8 JS engines with require() support?

---

@chicoxyzzy @ChALkeR @vkurchatkin sure! I hope I will survive all drinks at HolyJS :D.

[chicoxyzzy]

I've changed format a bit in alpha.4:

• omit patch versions
• add name field (either 'nodejs' or 'iojs')
• concatenate nodejs and iojs versions into one array

[iamstarkov]

Maybe we should rename package to js-cli-releases? But it is not CLI. browserless-js-releases? How it called correctly? :D

i'd suggest js-targets, or js-envs

[iamstarkov]

regarding last 2 versions, lts, i was thinking about uniq array of:

• last two versions as ['7.1.0', '6.9.1']
• lts as ['4.6.2', '6.9.1']

so its ['7.1.0', '6.9.1', '4.6.2']

[ai]

I like js-targets. But browsers are JS targets?

[iamstarkov]

in terms of babel compile targets, they are

[ai]

Babel is not only thing in the world 😉

[iamstarkov]

for sure, thats why i suggested js-envs, because browsers and nodejs and chakra are all environments where you can run js

[yavorsky]

@ai why?

Currently, we are trying to resolve at least browserslist config support to use browserslist ^1.5. But we have some problems after babel-core alpha.7 update. Now dirname is just a process.cwd instead of file's dirname path like browserslist accepts. Logan explained why it was updated.

But we would be very happy to have node as a supported target as well! Do you need some help with it? I wrote some thoughts about it in babel/babel-preset-env#108 and read all the comments above. I agree that we need to rename browserslist and targets.browsers for the preset-env.

Also, I think we could support more targets like electron. The only problem is the usage statistics.

[ai]

Ouh, sure.

[donaldpipowitch]

Hi everyone! In the last days I tried to look into ways how to create a "universal" libs which target multiple environments with a modern tooling in mind. I don't know the current state of the discussion above, because the last comments are nearly a year old and I don't know what happened offsite, but as I understood it there is commonly used format to express "all" the target environments for a lib.

1. browserslist "supports" non-browser environments like Electron, but not the probably most popular one Node, which this issue is about.
2. babel-preset-env, one popular consumer of browserslist, technically allows specifying browser environments and Node in a targets object, but according to this issue Target browsers and Node babel/babel#6611 this isn't really respected.
3. In the webpack community we currently discuss how to ideally build "universal" modules a little bit (Target browsers and Node babel/babel#6611 and Add target: "universal" webpack/webpack#6525) with interesting comments. Other environments people would like to see are things like web workers. Webpack currently has a target field where you can specify only a single target like node or it there is discussion to create special targets like universal which cover more environments. But you can't really specify multiple ones.

I wonder if these efforts could be unified somehow? In an ideal world I would like to see a package called something like env-targets (targets is already in use) which resolves for a .targets file (cosmic-config-like) which essentially works like browserslist, but with support for more targets or like the targets object in babel-preset-env. This .targets file could be used by babel-preset-env and webpack and more projects and would essentially superseed browserslist.

Would that be a worthwile goal? Do you know related discussions around that?

[ai]

@donaldpipowitch Yeap. I think Node.js must be in Browserslist.

The problems I see right now:

1. We need to rename config.
2. Not all current Browserslist queries can be applied to Node.js. For example, it is hard to get Node.js versions usage statistics.

So one way is to create some sort of wrap library. Which will take take two options (one for Node.js, one for browsers) and send second to Browserslist.

But 2 packages will be hard to maintaince. So there is a second way. Add special Node.js queries to Browserslist and add addition config name (.targets).

What do you think about it this 2 ways?

I could add Node.js support to Browserslist in few days if I will find good source with released Node.js versions.

[donaldpipowitch]

@ai I think that sounds good as well. Add Node.js support directly to browserslist and allow using a new config called .targets 👍

[ai]

👍 I will think about it at Friday.

[donaldpipowitch]

Hi there, just wanted to ask if you found time thinking about this issue a little bit. (But don't feel rushed. Take the time you need :))

[ai]

Hi. Oops, a lot of time spent :(. Sorry, I am right now in moving to New York.

You can help me with this issue. Can you try to find some config with Node.js versions and support dates?

[donaldpipowitch]

I am right now in moving to New York.

Cool! I just moved myself 😄 (But in the same city.) Good luck and a lot of fun in New York!

Can you try to find some config with Node.js versions and support dates?

I'll try 👍

[ai]

@MylesBorins here is a issue which I mentioned in email

[donaldpipowitch]

Can you try to find some config with Node.js versions and support dates?

@ai, would this work? https://raw.githubusercontent.com/nodejs/Release/master/schedule.json :)

[ai]

@donaldpipowitch good start. But we need also minor and patch versions.

[donaldpipowitch]

Because they include different levels of language support/language features?

[MylesBorins]

https://nodejs.org/download/release/index.tab
https://nodejs.org/download/release/index.json

these files are kept up to date with each release. You can get version, and versions of embedded stuff such as (V8)

[chicoxyzzy]

It seems like same as https://nodejs.org/dist/index.json which I used in https://github.com/chicoxyzzy/node-releases

[MylesBorins]

@chicoxyzzy indeed, they are aliases to one another

[chicoxyzzy]

@ai @yavorsky what do we need from node-releases to use it in browserlist and preset env?
We can even use Travis CI for automatic publications as @denysdovhan proposed earlier

[ai]

@chicoxyzzy automatic publications will be very useful.

Right now seems like node-releases is everything that we need. Awesome.

I will add Cult of Martians task for this issue.

[vostrik]

@ai @chicoxyzzy I created Pull Request to node-releases for adding Node.js release schedule. This schedule is needed for current issue.
chicoxyzzy/node-releases#2

[ai]

Done #253

[ai]

Released in 4.0