[WIP] Add node's "engines" option by yavorsky · Pull Request #114 · babel/babel-preset-env

yavorsky · 2017-01-01T18:05:40Z

Motivation:

In many cases, targets' node option is matching engines from project's package.json. Devs have to duplicate this value. In cases with ranges like > 0.12 they must determine next node.js version and specify it in env-preset's targets.
"current" or true option is not fully covering preset's mission. We could have last node, but maintain older versions.

So for ex:
babelrc

{
  presets: [
    [ "env", {
      "targets": {
        "node": "engines",
        "browsers": [ "chrome 54" ]
      }
    }]
  ]
}

package.json

  "engines" : { "node" : ">=0.12" }

will use targets:

{
  node: 0.12,
  chrome: 54
}

yavorsky · 2017-01-02T10:30:18Z

Also, we could use filterSatisfiedVersions, getVersionsFromList and desemverify from there to parse versions including ranges if target version is not a number.

targets {
  "node": ">=5.0",
  "chrome": "^1.1"
}

#107
#106

existentialism · 2017-01-02T15:14:40Z

@yavorsky I was thinking the same thing, in fact had a rough branch using semver dep as well!

On an aside, should we move adding the yarn lock file to a separate PR (similar to #59) with CI runs with and without it?

existentialism · 2017-01-02T15:15:11Z

+    });
+  });
+
+  describe("getLowestFromSemverValue", () => {


Nit, but may want a test * returns null?

Good point! Need to cover * as well. Thanks!

yavorsky · 2017-01-02T15:19:22Z

Oh, lock.file, always forget 😤. I think we must add it to .gitignore.

hzoo · 2017-01-04T17:41:43Z

cc @sindresorhus since you expressed this idea (although as more of a default) in babel/babel#3476 (comment)

yavorsky · 2017-01-06T14:14:31Z

Update:

envEngines support:
- Getting value from: BABEL_ENV -> NODE_ENV -> 'development'.
- If no devEngines found with development environment - trying to access engines.
Remove yarn.lock, add it to .gitignore.
Update tests:
- Cover '*' engines value
- Cover engines value with wrong format.
- Cover development/production environments.

hzoo · 2017-01-06T15:20:56Z

  "repository": "https://github.com/babel/babel-preset-env",
  "main": "lib/index.js",
+  "engines" : { 
+    "node" : ">=0.12.0"


Yes, updated

hzoo · 2017-01-06T15:21:19Z

+    "node" : ">=0.12.0"
+  },
+  "devEngines" : { 
+    "node" : ">= 4.x"


we can do 6 here (I dont remember)

sindresorhus · 2017-01-07T08:43:39Z

@hzoo Great improvement, but as you already commented, I'd like to see it as the default. Having the engine field defined means you're targeting a specific minimum Node.js version anyway, so would be less config.

hiroppy · 2017-01-07T08:48:40Z

 *.log
-.vscode
+.vscode
+yarn.lock


Why do you ignore yarn.lock?

@abouthiroppy yarn support will be added with the separate PR.

So, to prevent commiting it every time unless it will be added, let's place it to .gitignore.

hzoo · 2017-01-07T16:20:56Z

Having the engine field defined means you're targeting a specific minimum Node.js version anyway, so would be less config.

@sindresorhus I guess the only issue is that the node version is different than browser version if you are using it for front-end code. I can build with node 6 but still support ie?

Not sure how we could now to do it automatically since we don't know if it's a node project. However we could make a wrapper for this that assumes node?

Could make it babel-preset-env-node or ask for https://github.com/nkt/babel-preset-node @nkt? Would use the minimum of engines + current node? and have no config

yavorsky · 2017-01-07T16:27:30Z

@hzoo Maybe consider engines if no targets was specified?

# Conflicts: # .gitignore # package.json # src/index.js # src/utils.js # test/index.spec.js # yarn.lock

nkt · 2017-04-10T16:24:28Z

Hey guys, i've noticed you asked me for babel-preset-node. I'm ready to transfer this package name to community.

danielbayley · 2017-04-10T19:13:00Z

I'm currently finishing off a kind of wrapper API around this preset and the latest CoffeeScript [v2] (for easy/zero config, to hook up source maps properly and because I want it for a bunch of Atom packages…) and had started to impliment my own check for engines when it occured to me it would probably be better as a PR on here, then I found this one… Point being, I'm keen to see this merged, so anything I can do to help I'm in… what, [if any] current blockers are there?

One thing to mention also, is that in the case of Atom packages, engines will usually have an atom property specifying it's own version (which really just corresponds to a particular version of electron), so I'm wondering how to handle this… would that need to be filtered out or just be ignored by this preset anyway? It would be cool if it was automatically resolved to the correct version of electron, but that does feel kind of out of scope here…

Also +1 for getting rid of node: true

ELLIOTTCABLE · 2017-06-01T18:18:29Z

I'm with @yavorsky, here — I think node: true should be deprecated, in favour of an explicit (and required) string.

k15a · 2017-06-23T09:05:32Z

Hey,

that's an awesome feature. 🎉
Could we also add support for a new option which would take the engines object directly?

{
  "presets": [
    [ "env", {
      "targets": {
        "node": { "node" : ">=0.12" },
        "browsers": [ "chrome 54" ]
      }
    }]
  ]
}

That would allow people to get the information from another source and pass it directly to the preset. I think that wouldn't be too hard because we can basically reuse the current logic.

yavorsky · 2017-06-23T11:24:56Z

@k15a We can avoid node field duplicating and pass semver value directly.

{
  "presets": [
    [ "env", {
      "targets": {
        "node": ">=0.12"
      }
    }]
  ]
}

k15a · 2017-06-23T11:27:23Z

@yavorsky Does the node field also accept ranges? I thought it currently only accepts version numbers.

yavorsky · 2017-06-23T13:30:08Z

@k15a Not yet. When we will merge this PR it would be easy to handle semver values.

sheerun · 2017-10-02T11:50:44Z

Maybe @yavorsky @hzoo Maybe it could first respect engines in publishConfig. It would allow for different engines for development and different for publication.

hzoo · 2017-10-31T21:35:21Z

Thanks for the PR!

Now that babel-preset-env has stabilized, it has been moved into the main Babel mono-repo.
The move makes it much easier to release and develop in sync with the rest of Babel!

This repo will be made read-only, as all of the issues/labels have been moved over as well. Please report any bugs and open pull requests over on the main mono-repo (against master which is v7)

yavorsky added 9 commits December 28, 2016 17:01

Parse engines node’s version from package.json.

2d51bba

Remove logs, move some staff to utils.

3f60aeb

Fix linting.

3036ac5

Fix indentation.

0f1b25f

Add engines option to package.json.

3134576

Use options for isPluginRequired.

b88e5f8

Add node-engines to fixtures.

67f9c15

Add engines and getLowestFromSemverValue tests.

7a5da94

Fix lint warns.

b97d48b

existentialism reviewed Jan 2, 2017

View reviewed changes

yavorsky added 7 commits January 6, 2017 14:48

Remove yarn.lock

568e0dc

Add yarn.lock to gitignore.

899b906

Consider devEngines.

f1e3efd

devEngines gt 4.x.

29f7b6a

Add BABEL_ENV production/development cases.

f71eac9

Cover ‘*’ and wrong semver format.

2d22e03

Fix indentation.

0696ea9

Use chrome is a number in node-engines fixtures.

ef95087

hzoo reviewed Jan 6, 2017

View reviewed changes

hiroppy reviewed Jan 7, 2017

View reviewed changes

Update engines and devEngines.

1838b68

yavorsky added the i: enhancement label Mar 8, 2017

yvele mentioned this pull request Mar 27, 2017

Targeting minor version with a floating number: Does that make any sense? #227

Closed

existentialism mentioned this pull request Mar 28, 2017

Support target versions as strings #231

Merged

existentialism added Tag: New Feature and removed i: enhancement labels Mar 29, 2017

existentialism added this to the 2.0 milestone Mar 31, 2017

yavorsky changed the base branch from master to 2.0 April 7, 2017 20:30

yavorsky added 4 commits April 10, 2017 14:15

Merge branch '2.0' into node-engines

8d0c085

# Conflicts: # .gitignore # package.json # src/index.js # src/utils.js # test/index.spec.js # yarn.lock

After merge fixes.

20153f0

Fix environment

a42a0a8

Fix all supported versions list

ac38247

yavorsky changed the title ~~Add node's "engines" option~~ [WIP] Add node's "engines" option Apr 10, 2017

yavorsky added 2 commits April 10, 2017 18:24

Remove unused vars

9268e16

Find package.json recursively.

f16683e

Fix package path.

d8a97f0

hzoo mentioned this pull request Jun 22, 2017

Package.json engines as node target #358

Closed

cfnelson mentioned this pull request Jul 7, 2017

fix: babel transform-runtime bug Urigo/merge-graphql-schemas#69

Closed

sheerun mentioned this pull request Oct 2, 2017

Feature: Precompile dependencies based on their engines #435

Closed

hzoo closed this Oct 31, 2017

yavorsky mentioned this pull request Jan 15, 2018

Automatically transpile dependencies with babel-preset-env parcel-bundler/parcel#559

Merged

4 tasks

existentialism mentioned this pull request Jan 27, 2018

[preset-env] target.node=true should use package.engines.node babel/babel#7277

Open

               *.log
-              .vscode

                
                    No newline at end of file
+              .vscode
+              yarn.lock

                
                    No newline at end of file

Uh oh!

Conversation

yavorsky commented Jan 1, 2017

Uh oh!

yavorsky commented Jan 2, 2017

Uh oh!

existentialism commented Jan 2, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yavorsky commented Jan 2, 2017

Uh oh!

hzoo commented Jan 4, 2017

Uh oh!

yavorsky commented Jan 6, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sindresorhus commented Jan 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yavorsky Jan 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hzoo commented Jan 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yavorsky commented Jan 7, 2017

Uh oh!

nkt commented Apr 10, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

danielbayley commented Apr 10, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ELLIOTTCABLE commented Jun 1, 2017

Uh oh!

k15a commented Jun 23, 2017

Uh oh!

yavorsky commented Jun 23, 2017

Uh oh!

k15a commented Jun 23, 2017

Uh oh!

yavorsky commented Jun 23, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sheerun commented Oct 2, 2017

Uh oh!

hzoo commented Oct 31, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants

yavorsky commented Jan 6, 2017 •

edited

Loading

sindresorhus commented Jan 7, 2017 •

edited

Loading

yavorsky Jan 7, 2017 •

edited

Loading

hzoo commented Jan 7, 2017 •

edited

Loading

nkt commented Apr 10, 2017 •

edited

Loading

danielbayley commented Apr 10, 2017 •

edited

Loading

yavorsky commented Jun 23, 2017 •

edited

Loading