Postinstall ignore the project specific .npmrc - IMPORTANT FOR CI

[deleonio]

It would be important that a postinstall consider the project specific configurations.

Inside a CI Pipeline we does not have root privileges - so we only can change the local .npmrc.

But the npm install of OS specific esbuild binary does not use this settings.

[evanw]

Can you say more about your situation? What does your .npmrc configure? What OS are you running on? The install script forwards the environment variables from the parent npm to the child npm, so in theory that should let the config values be carried over.

I just tried this out locally with the https-proxy setting and it appears to work. Here's what I tried:

• Create esbuild-0.8.16.tgz by running npm pack in the ./npm/esbuild folder in this repo
• Create a new folder with a package.json file containing {} and a .npmrc file containing https-proxy=http://192.168.0.100
• Remove esbuild's download cache at ~/.cache/esbuild/bin
• In that new folder, run npm install ../path/to/esbuild-0.8.16.tgz

When I do this the installation of esbuild never completes, which indicates to me that it's picking up the proxy setting from .npmrc.

[prantlf]

@evanw, the postinstall script of the main esbuild NPM module, which installs the platform-specific executable, ignores the NPM registry setting from .npmrc. It always downloads from https://registry.npmjs.org.

Companies with many CI/CD pipelines do not connect to the public NPM registry. They use either caching proxies or synchronising registries running on their internal infrastructure. They need to prevent an excessive amount of requests to the public registry., which would be against the NPM policy and an access to the NPM registry would be cut for such company. Some companies block access to the public NPM registry on the build machines to prevent such problem.

You should adhere to the NPM registry setting in .npmrc, as long as you do not use npm to install the platform-specific binaries. An example of the configuration line setting other NPM registry than the default one:

registry=http://artifactory.company.net/artifactory/api/npm/NPM_ORG/

You could also allow configuring the path to the cache directory, which is hardcoded to $HOME. PNPM allows to place to cache directory to the build directory instead of to the user home, so that GitLab is able to cache it among stages of the pipeline.

@martinoppitz, the postinstaller does not use npm and thus neither .npmrc. What settings from .npmrc do you need to support?

[evanw]

@evanw, the postinstall script of the main esbuild NPM module, which installs the platform-specific executable, ignores the NPM registry setting from .npmrc. It always downloads from https://registry.npmjs.org.

That's only used as a fallback if running npm itself fails. It's meant as a hedge against weird situations where npm is either broken or not installed at all. An example of this is #274, where the npm command didn't exist.

@martinoppitz, the postinstaller does not use npm and thus neither .npmrc.

The postinstall does use npm. It's right here, above the code you linked to. This is necessary to get the downloads to work in situations where people have a custom proxy and/or a custom registry configured. This is already picking up settings from .npmrc in my tests, as described above with https-proxy.

What settings from .npmrc do you need to support?

This information is going to be needed to make more progress on this issue.

[deleonio]

Hello @evanw and @prantlf ,

it is interessting - because the postinstall consider the .npmrc registry value - but he not ignore self signed certificates.

For example .npmrc:

registry=https://company/nexus/.../npm-group
strict-ssl=false

Result of npm postinstall:

1. registry of .npmrc used
2. strict-ssl of .npmrc not used

WHY?

• Is it a npm bug?
• Is it because of the npm options? (--loglevel=error --prefer-offline --no-audit --progress=false)

[evanw]

Thanks for following up. I was able to reproduce this locally using https://verdaccio.org/. It looks like the npm options that esbuild passes are not the cause of this. The reason seems to be that the .npmrc file sets the npm_config_registry environment variable correctly but sets the npm_config_strict_ssl environment variable to an empty string instead of false (it defaults to true).

I'm not sure if this is a bug in npm or if this is by design, but it seems like a bug to me. Here's where false values become empty strings when writing .npmrc to environment variables before esbuild's install script is run:

https://github.com/npm/npm-lifecycle/blob/bfb6f73853a222a3f35a1a6651b0756816e2ed87/index.js#L464

And here is where empty strings from environment variables are ignored in the nested npm command, which then causes the strict-ssl setting to fall back to the default value of true:

https://github.com/npm/cli/blob/48753bbdfdd4ef5986e4cebef8aa0972ea27d13d/lib/config/core.js#L273

Which version of npm are you using? Is it version 6? Does the problem disappear if you use version 7 instead? I can only reproduce this locally using version 6, not version 7.

[deleonio]

Hello @evanw ,

the solution for this magic behavior is to set a environment variable.

NODE_EXTRA_CA_CERTS with path to a company root ca.

I don't know, why the postinstall ignores the project specific npm config belongs to ca[] or strict-ssl=false

[evanw]

Closing because this is a bug in npm, not in esbuild. It seems like one workaround is to use npm 7 instead of npm 6.