New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

node.js versions support #75

Closed
ai opened this Issue Oct 13, 2016 · 57 comments

Comments

Projects
None yet
8 participants
@ai
Member

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 14, 2016

Contributor

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.

Contributor

chicoxyzzy commented Nov 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Nov 14, 2016

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 14, 2016

Contributor

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 :)

Contributor

chicoxyzzy commented Nov 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Nov 14, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 14, 2016

Contributor

I'll do it

Contributor

chicoxyzzy commented Nov 14, 2016

I'll do it

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Nov 14, 2016

Member

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

Member

ai commented Nov 14, 2016

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

@chicoxyzzy

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 15, 2016

Contributor

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 🤖

Contributor

chicoxyzzy commented Nov 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Nov 15, 2016

Member

@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)
Member

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 15, 2016

Contributor
  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

Contributor

chicoxyzzy commented Nov 15, 2016

  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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Nov 15, 2016

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Nov 15, 2016

Member

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

Member

ai commented Nov 15, 2016

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

@iamstarkov

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Nov 15, 2016

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

@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

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Nov 15, 2016

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

iamstarkov commented Nov 15, 2016

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

@chicoxyzzy

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 15, 2016

Contributor

@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

Contributor

chicoxyzzy commented Nov 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Nov 15, 2016

@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

iamstarkov commented Nov 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 15, 2016

Contributor

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

Contributor

chicoxyzzy commented Nov 15, 2016

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

@chicoxyzzy

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 16, 2016

Contributor

@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

Contributor

chicoxyzzy commented Nov 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Nov 16, 2016

Member

@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 ;).
Member

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Nov 16, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 16, 2016

Contributor
  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! 😉🍺

Contributor

chicoxyzzy commented Nov 16, 2016

  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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Nov 16, 2016

Member
  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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 16, 2016

Contributor

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
Contributor

chicoxyzzy commented Nov 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov 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

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

iamstarkov 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

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

@iamstarkov

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Nov 16, 2016

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']

iamstarkov commented Nov 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Nov 16, 2016

Member

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

Member

ai commented Nov 16, 2016

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

@iamstarkov

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Nov 16, 2016

in terms of babel compile targets, they are

iamstarkov commented Nov 16, 2016

in terms of babel compile targets, they are

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Nov 16, 2016

Member

Babel is not only thing in the world 😉

Member

ai commented Nov 16, 2016

Babel is not only thing in the world 😉

@iamstarkov

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Nov 16, 2016

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

iamstarkov commented Nov 16, 2016

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

@iamstarkov

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Nov 16, 2016

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

iamstarkov commented Nov 16, 2016

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

@chicoxyzzy

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 16, 2016

Contributor

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

Contributor

chicoxyzzy commented Nov 16, 2016

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

@iamstarkov

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Nov 16, 2016

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.

iamstarkov commented Nov 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Nov 16, 2016

Contributor

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

Contributor

chicoxyzzy commented Nov 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Nov 16, 2016

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

iamstarkov commented Nov 16, 2016

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

@iamstarkov

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Nov 16, 2016

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

iamstarkov commented Nov 16, 2016

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 Dec 7, 2016

Merged

WIP Post #1014

6 of 6 tasks complete
@denysdovhan

This comment has been minimized.

Show comment
Hide comment
@denysdovhan

denysdovhan Dec 25, 2016

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.

denysdovhan commented Dec 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Apr 21, 2017

Member

Seems like babel-preset-env doesn’t need it.

/cc @yavorsky

Member

ai commented Apr 21, 2017

Seems like babel-preset-env doesn’t need it.

/cc @yavorsky

@ai ai closed this Apr 21, 2017

@yavorsky

This comment has been minimized.

Show comment
Hide comment
@yavorsky

yavorsky Apr 21, 2017

@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.

yavorsky commented Apr 21, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Apr 21, 2017

Member

Ouh, sure.

Member

ai commented Apr 21, 2017

Ouh, sure.

@donaldpipowitch

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Mar 21, 2018

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 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 (babel/babel#6611 and 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?

donaldpipowitch commented Mar 21, 2018

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 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 (babel/babel#6611 and 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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 21, 2018

Member

@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.

Member

ai commented Mar 21, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Mar 22, 2018

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

donaldpipowitch commented Mar 22, 2018

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

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 22, 2018

Member

👍 I will think about it at Friday.

Member

ai commented Mar 22, 2018

👍 I will think about it at Friday.

@donaldpipowitch

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Apr 9, 2018

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 :))

donaldpipowitch commented Apr 9, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Apr 9, 2018

Member

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?

Member

ai commented Apr 9, 2018

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

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Apr 9, 2018

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 👍

donaldpipowitch commented Apr 9, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Apr 16, 2018

Member

@MylesBorins here is a issue which I mentioned in email

Member

ai commented Apr 16, 2018

@MylesBorins here is a issue which I mentioned in email

@donaldpipowitch

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Apr 18, 2018

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 :)

donaldpipowitch commented Apr 18, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Apr 18, 2018

Member

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

Member

ai commented Apr 18, 2018

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

@donaldpipowitch

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Apr 18, 2018

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

donaldpipowitch commented Apr 18, 2018

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

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Apr 18, 2018

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)

MylesBorins commented Apr 18, 2018

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

This comment has been minimized.

Show comment
Hide comment
Contributor

chicoxyzzy commented Apr 18, 2018

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Apr 18, 2018

@chicoxyzzy indeed, they are aliases to one another

MylesBorins commented Apr 18, 2018

@chicoxyzzy indeed, they are aliases to one another

@chicoxyzzy

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Apr 18, 2018

Contributor

@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

Contributor

chicoxyzzy commented Apr 18, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Apr 18, 2018

Member

@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.

Member

ai commented Apr 18, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@vostrik

vostrik Apr 26, 2018

Contributor

@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

Contributor

vostrik commented Apr 26, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Jun 13, 2018

Member

Done #253

Member

ai commented Jun 13, 2018

Done #253

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Jun 26, 2018

Member

Released in 4.0

Member

ai commented Jun 26, 2018

Released in 4.0

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