Improve changelog entry for v119

[OliverJAsh]

When we upgraded, things broke because NPM_CONFIG_PRODUCTION stopped working, however this was not a clear breaking change from the changelog. Thus, I would like to improve the changelog for other users who may also experience this.

[jmorrell]

I think I can clarify a bit, NPM_CONFIG_PRODUCTION and YARN_PRODUCTION are not a Heroku buildpack convention. They are the env vars used by each tools themselves.

The Node buildpack did set NPM_CONFIG_PRODUCTION=true as a way of controlling npm, and a few users used this to determine that they were running on Heroku, but that was never the intended use. This led to this release causing issues for a few users.

[jmorrell]

I think this is more accurately phrased as:

No longer export NPM_CONFIG_PRODUCTION=true by default

[OliverJAsh]

Re. #633 (comment), I was trying to communicate that potential usage of NPM_CONFIG_PRODUCTION=false would have to be replaced with YARN_PRODUCTION=false.

[OliverJAsh]

@jmorrell My perspective of this was that we were setting NPM_CONFIG_PRODUCTION=false to disable pruning of Yarn dev dependencies. This worked until we tried to upgrade. Eventually we discovered we had to replace NPM_CONFIG_PRODUCTION=false with YARN_PRODUCTION=false.

They are the env vars used by each tools themselves.

Hmm, but they seem to be used by the buildpack, no? E.g.

heroku-buildpack-nodejs/lib/dependencies.sh

Line 187 in 5d1e6f7

elif [ -n "$YARN_PRODUCTION" ]; then

[jmorrell]

Hmm, but they seem to be used by the buildpack, no? E.g.

Yes, if a user has set this to either true or false then pruning is unnecessary because Yarn will already have installed the desired set of dependencies the first time. This happened in release v121 though. Here's the relevant discussion:

#529
#526

[jmorrell]

My perspective of this was that we were setting NPM_CONFIG_PRODUCTION=false to disable pruning of Yarn dev dependencies

I don't believe this was ever the way the buildpack worked. We never checked the npm env var when choosing whether or not to prune with yarn: https://github.com/heroku/heroku-buildpack-nodejs/pull/519/files#diff-b796d034e8c512aaeb727f89e3598620R97 Can you say more about this?

[jmorrell]

this happened in release v121 though

I was inaccurate here. We were checking in v119, it was expanded in v121

[jmorrell]

As an aside: This whole change was necessary for users and eliminated a whole class of errors that used to plague support, but it was a nightmare to pull off with a minimum of disruption to existing users 😞 I'm sorry you're hitting issues updating

[OliverJAsh]

I don't believe this was ever the way the buildpack worked. We never checked the npm env var when choosing whether or not to prune with yarn

Aha, you're right. We were specifying NPM_CONFIG_PRODUCTION=false but that would only have applied for npm, not for Yarn (which we use). In that case, the breaking behaviour wasn't a change in NPM_CONFIG_PRODUCTION but rather the fact the buildpack started to automatically prune Yarn dependencies. In that case the changelog makes sense as it is. Thanks for clarifying!