Allow 'production' ENV to take precedence over NODE_ENV

[joeyespo]

This fixes #1975.

The motivation is to fix the compatibility issue so that Yarn can be used in place of npm on Heroku (related buildpack issue). In this case, when you need to install devDependencies, as documented here.

Test plan

A test is included.

(I also tested locally on my setup and observed that the devDependencies were indeed installed to node_modules when both NODE_ENV=production and NPM_CONFIG_PRODUCTION=false were set.)

[joeyespo]

Huh. The test is passing locally. Digging in to see why it isn't working on CI.

[joeyespo]

I'm not sure why my first approach wasn't working. It worked locally for some reason. (Anyone have any ideas?) But using the same method as #1455 worked.

This is all good to go.

[bestander]

@joeyespo, do we have a support for --no-production?
Should it override ENV vars?

• needs a rebase

[joeyespo]

@bestander Rebased.

One test is failing due to Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. Any ideas?

There's no --no-production to my knowledge, but this does work exactly like npm where you can set NPM_CONFIG_PRODUCTION=false in your config.

[bestander]

@joeyespo, this is a known problem, we'll sort it out separately

[bestander]

There's no --no-production to my knowledge, but this does work exactly like npm where you can set NPM_CONFIG_PRODUCTION=false in your config.

My concern is that if NODE_ENV is set to production overriding it can only be done with another env variable, e.g. YARN_PRODUCTION.
Sometimes people don't have full control over environment variables in the system and overriding with an arg can be a more obvious API.

In npm you can do --production=false and it will override env variables.
Can you do similar thing for Yarn?

[adamreisnz]

What if the opposite is true, where people only have control over env variables rather than CLI arguments? E.g. when running on Heroku under the constraints as described in #2283

[joeyespo]

@bestander

and overriding with an arg can be a more obvious API

I agree with you on the usefulness of that. Yarn currently doesn't support it. (It appears npm does.)

This PR fixes real production compatibility issue though (heroku/heroku-buildpack-nodejs#337). As of #1455, you can already set NODE_ENV to production without any way to override it. Heroku sets this, and documents that the way to override it is with another ENV. This PR fixes that specific case.

The --production=false case is another backwards incompatibility. It's independent of this fix though and may require some upfront discussion, so I think it might be better to address that in a new issue/PR instead of ultimately delaying this one.

[chadly]

related #2167

[joeyespo]

@chadly Perfect 👍

@bestander Given that the test timeout is a known thing to be sorted out separately, this should be ready to go. Need anything else from me?

[bestander]

Sounds reasonable, @joeyespo, thanks for the contribution!