Improve mode/NODE_ENV defaults and interaction #972

edmorley · 2018-06-29T20:53:32Z

Previously the only way to override mode was by passing --mode on the command line. However this is not possible with all tools, since some (such as karma) reject unrecognised arguments.

Now:

mode is derived from NODE_ENV if --mode wasn't passed, and !production NODE_ENV falls back to mode development.
if --mode is passed, it takes priority over NODE_ENV.
if neither mode nor NODE_ENV is defined, then NODE_ENVis set toproduction, however mode` is left undefined, which causes webpack to output a helpful warning about relying on defaults.
the template test runner configs set a default NODE_ENV of test.
@neutrinojs/stylelint now also correctly sets failOnError.

Fixes #900.
Fixes #971.
Closes #955.

edmorley · 2018-06-29T20:54:27Z

Once we agree on the behaviour/UX I'll fix/add some tests :-)

edmorley · 2018-06-29T20:57:28Z

.eslintrc.js

@@ -1,3 +1,5 @@
 const neutrino = require('./packages/neutrino');

+process.env.NODE_ENV = process.env.NODE_ENV || 'lint';


Possible values instead of "lint" might be "test" or "production". Though given we use "test" for karma.config.js etc, it seems wrong to just call this "production".

ESLint config conditionals that choose to rely on NODE_ENV (eg enabling/disabling the no-console rule) should be using NODE_ENV !== 'development' rather than NODE_ENV === 'production' for compatibility with NODE_ENV='test' anyway -- so using NODE_ENV='lint' doesn't seem like it would cause any more problems.

@eliperelman thoughts about this part?

I'm OK with this, although my initial gut reaction wishes this existed in eslint() instead of being dotfile boilerplate.

Yeah me too -- though I guess that would mean we would have to change the whole way the middlewares are instantiated.

Yeah which is too much right now. The thing that prevents us from doing this is not being able to reliably infer when the NODE_ENV was set by Neutrino vs. the environment.

I know this sounds crazy, but...

What if the Neutrino instance had options stating whether or not mode and NODE_ENV were specified, and the middleware could control the values?

// packages/neutrino/index.js const neutrino = new Neutrino({ mode: yargs.argv.mode, NODE_ENV: process.env.NODE_ENV }) // packages/web/index.js if (!neutrino.options.NODE_ENV) { process.env.NODE_ENV = 'production'; } // packages/karma/index.js neutrino.register('karma', (neutrino, override) => config => { if (!neutrino.options.NODE_ENV) { process.env.NODE_ENV = 'test'; } });

Obviously the above isn't correct, but conceptual. Thoughts?

That definitely gets us closer, however if I follow correctly, it would mean that the web preset (and any others) see the NODE_ENV as 'production' and not 'test', thereby meaning the parts of the config they contribute to the karma config, are using the wrong NODE_ENV.

Therefore it seems that the only way to solve this is make the meat of the presets be a step that occurs after they register themselves.

ie:

// registers the presets and what output commands they include, // but doesn't actually generate any config or adjust NODE_ENV neutrino.use(some_lint_preset); neutrino.use(some_build_preset); neutrino.use(some_test_preset); // The output function then sets NODE_ENV if undefined (in this case to `"test"`) // and then actually generates the config, where all presets get to see `NODE_ENV=test` neutrino.karma();

(but that's a major change and would mean backwards incompatibility with all existing presets)

I think keeping middleware compat is more important here.

edmorley · 2018-06-29T21:01:02Z

packages/neutrino/index.js

+    // Development mode is most appropriate for a !production NODE_ENV (such as `NODE_ENV=test`).
+    mode = (process.env.NODE_ENV === 'production') ? 'production' : 'development';
+  } else {
+    throw new Error('Either --mode must be specified via the CLI, or else NODE_ENV be defined.');


Alternatives to throwing are:

default to NODE_ENV='production' and mode='production'

default to NODE_ENV='production' and don't set mode at all. This would mean for workflows that include a webpack compile (ie not yarn lint), webpack would output the "no mode was specified, using production" warning message, which might help solve the "prevent people from accidentally omitting mode/NODE_ENV` concern.

Both of the alternatives would mean we could drop the process.env.NODE_ENV = ... boilerplate from the template .eslintrc.js files -- though we would still need it for karma.config.js.

I'm on the fence as to which of these three options is best.

@eliperelman and this?

edmorley · 2018-06-29T21:01:20Z

packages/stylelint/index.js

@@ -6,6 +6,8 @@ module.exports = (neutrino, { pluginId = 'stylelint', ...opts } = {}) => {
    configBasedir: neutrino.options.root,
    files: '**/*.+(css|scss|sass|less)',
    context: neutrino.options.source,
+    // Fail for all of 'production', 'lint' and 'test'.
+    failOnError: process.env.NODE_ENV !== 'development',


This fixes #971.

edmorley · 2018-06-29T21:02:03Z

packages/eslint/index.js

@@ -84,7 +84,8 @@ module.exports = (neutrino, opts = {}) => {
    include: !opts.include ? [neutrino.options.source, neutrino.options.tests] : undefined,
    eslint: {
      cache: true,
-      failOnError: neutrino.config.get('mode') === 'production',
+      // Fail for all of 'production', 'lint' and 'test'.
+      failOnError: process.env.NODE_ENV !== 'development',


I've flipped this, so it is set to true for yarn test too.

eliperelman · 2018-07-02T13:16:52Z

packages/neutrino/index.js


-  if (!process.env.NODE_ENV) {
+  if (mode) {
    process.env.NODE_ENV = mode;


Here we force NODE_ENV to always be the same value as --mode, but that's not what we want right? What about NODE_ENV=development webpack --mode production?

This was intentional (there's a note in the PR description), for the reasons under scenario G here:
#955 (comment)

...though open to counter-arguments :-)

edmorley · 2018-07-03T15:30:54Z

@eliperelman, any more thoughts on the UX choices? I'm keen to get them finalised, so I can updated the tests in this PR, then press on with the overall docs update in another PR.

(Context: I really want to get Treeherder builds faster soon (ie next week or two), which means a Neutrino 9 alpha by then, or else stopping using Neutrino and just switching to plain webpack)

eliperelman · 2018-07-03T15:57:24Z

I still a little uneasy about #972 (comment) but I can't articulate my issue with it. I'd say let's roll with it, test it out, and revise if necessary.

(Cancelling review until tests are updated)

Previously the only way to override `mode` was by passing `--mode` on the command line. However this is not possible with all tools, since some (such as karma) reject unrecognised arguments. Now: * `mode` is derived from `NODE_ENV` if `--mode` wasn't passed, and !production `NODE_ENV` falls back to mode `development`. * if `--mode` is passed, it takes priority over `NODE_ENV`. * if neither `mode` nor `NODE_ENV is defined, then `NODE_ENV` is set to `production`, however `mode` is left undefined, which causes webpack to output a helpful warning about relying on defaults. * the template test runner configs set a default `NODE_ENV` of `test`. * `@neutrinojs/stylelint` now also correctly sets `failOnError`. Fixes #900. Fixes #971. Closes #955.

edmorley · 2018-07-13T18:28:08Z

I've updated the PR - changes are:

if neither NODE_ENV nor mode is defined, now instead of throwing, NODE_ENV is set to production and mode left as undefined. This avoids having to set a default NODE_ENV in .eslintrc.js, and leaving mode as undefined means that when webpack is used, the webpack "mode wasn't set, falling back to defaults" message is shown, which should help educate users.
the tests have been updated / additional coverage added.

eliperelman

This looks good. I'm willing to roll with it and see how it does.

edmorley · 2018-07-13T19:07:11Z

👍

edmorley added the breaking change label Jun 29, 2018

edmorley added this to the v9 milestone Jun 29, 2018

edmorley self-assigned this Jun 29, 2018

edmorley changed the title ~~Improve mode and NODE_ENV defaults and interaction~~ Improve mode/NODE_ENV defaults and interaction Jun 29, 2018

edmorley commented Jun 29, 2018

View reviewed changes

edmorley requested a review from eliperelman June 29, 2018 21:05

edmorley added bug and removed breaking change labels Jul 1, 2018

eliperelman reviewed Jul 2, 2018

View reviewed changes

eliperelman previously approved these changes Jul 3, 2018

View reviewed changes

eliperelman mentioned this pull request Jul 10, 2018

Web preset option to enable sourcemaps in production #676

Closed

eliperelman approved these changes Jul 13, 2018

View reviewed changes

edmorley merged commit 2dce8d2 into neutrinojs:master Jul 13, 2018

edmorley deleted the mode-NODE_ENV-defaults branch July 13, 2018 19:07

edmorley mentioned this pull request Aug 1, 2018

Write migration guide for Neutrino 9 #944

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve mode/NODE_ENV defaults and interaction #972

Improve mode/NODE_ENV defaults and interaction #972

edmorley commented Jun 29, 2018 •

edited

edmorley commented Jun 29, 2018 •

edited

edmorley Jun 29, 2018

edmorley Jul 4, 2018

eliperelman Jul 5, 2018

edmorley Jul 5, 2018

eliperelman Jul 5, 2018

eliperelman Jul 5, 2018 •

edited

edmorley Jul 5, 2018 •

edited

edmorley Jul 5, 2018

eliperelman Jul 10, 2018

edmorley Jun 29, 2018 •

edited

edmorley Jul 4, 2018

edmorley Jun 29, 2018

edmorley Jun 29, 2018

eliperelman Jul 2, 2018

edmorley Jul 2, 2018

edmorley commented Jul 3, 2018

eliperelman commented Jul 3, 2018

edmorley commented Jul 13, 2018

eliperelman left a comment

edmorley commented Jul 13, 2018

		@@ -1,3 +1,5 @@
		const neutrino = require('./packages/neutrino');

		process.env.NODE_ENV = process.env.NODE_ENV \|\| 'lint';

Improve mode/NODE_ENV defaults and interaction #972

Improve mode/NODE_ENV defaults and interaction #972

Conversation

edmorley commented Jun 29, 2018 • edited

edmorley commented Jun 29, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eliperelman Jul 5, 2018 • edited

Choose a reason for hiding this comment

edmorley Jul 5, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

edmorley Jun 29, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

edmorley commented Jul 3, 2018

eliperelman commented Jul 3, 2018

edmorley commented Jul 13, 2018

eliperelman left a comment

Choose a reason for hiding this comment

edmorley commented Jul 13, 2018

edmorley commented Jun 29, 2018 •

edited

edmorley commented Jun 29, 2018 •

edited

eliperelman Jul 5, 2018 •

edited

edmorley Jul 5, 2018 •

edited

edmorley Jun 29, 2018 •

edited