node.js versions support #75

Open
ai opened this Issue Oct 13, 2016 · 35 comments

Projects

None yet

4 participants

@ai
Owner
ai commented Oct 13, 2016

@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
chicoxyzzy commented Nov 14, 2016 edited

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
Owner
ai commented Nov 14, 2016

@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
chicoxyzzy commented Nov 14, 2016 edited

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
Owner
ai commented Nov 14, 2016

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
Owner
ai commented Nov 14, 2016

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

@chicoxyzzy
chicoxyzzy commented Nov 15, 2016 edited

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
Owner
ai commented Nov 15, 2016

@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
Owner
ai commented Nov 15, 2016

@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
Owner
ai commented Nov 15, 2016

@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
Owner
ai commented Nov 16, 2016

@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
Owner
ai commented Nov 16, 2016

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

@chicoxyzzy
chicoxyzzy commented Nov 16, 2016 edited
  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
Owner
ai commented Nov 16, 2016
  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
chicoxyzzy commented Nov 16, 2016 edited

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
iamstarkov commented Nov 16, 2016 edited

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
Owner
ai commented Nov 16, 2016

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

@iamstarkov

in terms of babel compile targets, they are

@ai
Owner
ai commented Nov 16, 2016

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

@iamstarkov

tbh there are more envs where you can run js, but thats another story

@chicoxyzzy

TBH I don't have plans to add something other than nodejs to my repo

@iamstarkov

regarding major keyword. i think its usefull but as modifier. say last two versions, lts | major will produce ['7', '6', '4'] and you can generate .travis.yml straight away.

though its much easier to perform this transformation with code, than to learn syntax of modifier.

@chicoxyzzy
chicoxyzzy commented Nov 16, 2016 edited

TBH I don't have plans to add something other than nodejs to my repo

But if you feel that current name isn't good for some reason please move that conversation to https://github.com/chicoxyzzy/node-releases/issues

Let's concentrate on browserlist here

@iamstarkov

node-releases is good name because project is concerned only about nodejs

@iamstarkov

i was thinking we are talking about browserslist renaming as far as after this pr it will let to query not only browsers but node versions as well

@chicoxyzzy chicoxyzzy referenced this issue in babel/babel.github.io Dec 7, 2016
Merged

WIP Post #1014

6 of 6 tasks complete
@denysdovhan

add a bot which will poll Node.js website every couple hours (serve it on Heroku?)

Hey, @chicoxyzzy, TravisCI is testing cron jobs for scheduled builds. Probably, it might be handy for this case.

@ai ai referenced this issue in babel/babel-preset-env Jan 4, 2017
Open

Promote shareable browserslist config #108

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment