create-react-app is ignoring yarn's registry config value - create-react-app

I am not sure if this is a problem with create-react-app or yarn.
I am trying to use create-react-app. It seems to use yarn under the hood to fetch dependencies, but yarn is ignoring its own registry config setting and tries to download packages directly from https://registry.yarnpkg.com/.
This is the output when I try to use create-react-app. You can see at the end that yarn ignores the registry config setting:
$ npx create-react-app#2.1.2 my-app --verbose --registry "http://myownregistry:1234/"
npm info it worked if it ends with ok
npm info using npm#6.4.1
npm info using node#v10.13.0
npm timing npm Completed in 153ms
npm info ok
npx: installed 63 in 72.714s
Creating a new React app in C:\work\my-app.
Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...
yarn add v1.13.0
verbose 0.399 Checking for configuration file "C:\\work\\my-app\\.npmrc".
verbose 0.4 Checking for configuration file "C:\\Users\\jbloggs\\.npmrc".
verbose 0.4 Found configuration file "C:\\Users\\jbloggs\\.npmrc".
verbose 0.401 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 0.401 Checking for configuration file "C:\\work\\my-app\\.npmrc".
verbose 0.402 Checking for configuration file "C:\\work\\.npmrc".
verbose 0.406 Checking for configuration file "C:\\work\\my-app\\.yarnrc".
verbose 0.406 Checking for configuration file "C:\\Users\\jbloggs\\.yarnrc".
verbose 0.406 Found configuration file "C:\\Users\\jbloggs\\.yarnrc".
verbose 0.407 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 0.407 Checking for configuration file "C:\\work\\my-app\\.yarnrc".
verbose 0.407 Checking for configuration file "C:\\work\\.yarnrc".
verbose 0.417 current time: 2019-01-21T16:43:06.912Z
[1/4] Resolving packages...
verbose 0.637 Performing "GET" request to "http://myownregistry:1234/react".
verbose 2.827 Request "http://myownregistry:1234/react" finished with status code 200.
verbose 2.837 Performing "GET" request to "http://myownregistry:1234/loose-envify".
verbose 2.839 Performing "GET" request to "http://myownregistry:1234/scheduler".
[... lots of similar lines removed lines removed ...]
verbose 23.218 Request "http://myownregistry:1234/string_decoder" finished with status code 200.
[2/4] Fetching packages...
verbose 23.473 Performing "GET" request to "https://registry.yarnpkg.com/object-assign/-/object-assign-4.1.1.tgz".
verbose 23.483 Performing "GET" request to "https://registry.yarnpkg.com/prop-types/-/prop-types-15.6.2.tgz".
verbose 23.486 Performing "GET" request to "https://registry.yarnpkg.com/loose-envify/-/loose-envify-1.4.0.tgz".
verbose 23.492 Performing "GET" request to "https://registry.yarnpkg.com/js-tokens/-/js-tokens-4.0.0.tgz".
verbose 23.514 Performing "GET" request to "https://registry.yarnpkg.com/babel-core/-/babel-core-7.0.0-bridge.0.tgz".
verbose 23.518 Performing "GET" request to "https://registry.yarnpkg.com/#babel/core/-/core-7.1.6.tgz".
verbose 23.52 Performing "GET" request to "https://registry.yarnpkg.com/#svgr/webpack/-/webpack-2.4.1.tgz".
verbose 23.531 Performing "GET" request to "https://registry.yarnpkg.com/babel-eslint/-/babel-eslint-9.0.0.tgz".
Missing dependencies in package.json
However, if I use Yarn on its own, it will use the registry config value.
$ yarn add object-assign#4.1.1 --verbose
yarn add v1.13.0
verbose 0.375 Checking for configuration file "C:\\work\\.npmrc".
verbose 0.376 Checking for configuration file "C:\\Users\\jbloggs\\.npmrc".
verbose 0.376 Found configuration file "C:\\Users\\jbloggs\\.npmrc".
verbose 0.378 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 0.379 Checking for configuration file "C:\\work\\.npmrc".
verbose 0.383 Checking for configuration file "C:\\work\\.yarnrc".
verbose 0.383 Checking for configuration file "C:\\Users\\jbloggs\\.yarnrc".
verbose 0.383 Found configuration file "C:\\Users\\jbloggs\\.yarnrc".
verbose 0.384 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 0.384 Checking for configuration file "C:\\work\\.yarnrc".
verbose 0.39 current time: 2019-01-21T16:48:15.659Z
info No lockfile found.
[1/4] Resolving packages...
verbose 0.488 Performing "GET" request to "http://myownregistry:1234/object-assign".
verbose 3.892 Request "http://myownregistry:1234/object-assign" finished with status code 200.
[2/4] Fetching packages...
verbose 3.932 Performing "GET" request to "http://myownregistry:1234/object-assign/-/object-assign-4.1.1.tgz".
[3/4] Linking dependencies...
verbose 4.143 Creating directory "C:\\work\\node_modules\\object-assign".
verbose 4.146 Copying "C:\\Users\\jbloggs\\AppData\\Local\\Yarn\\Cache\\v4\\npm-object-assign-4.1.1-2109adc7965887cfc05cbbd442cac8bfbb360863\\node_modules\\object-assign\\index.js" to "C:\\work\\node_modules\\object-assign\\index.js".
verbose 4.147 Copying "C:\\Users\\jbloggs\\AppData\\Local\\Yarn\\Cache\\v4\\npm-object-assign-4.1.1-2109adc7965887cfc05cbbd442cac8bfbb360863\\node_modules\\object-assign\\license" to "C:\\work\\node_modules\\object-assign\\license".
verbose 4.147 Copying "C:\\Users\\jbloggs\\AppData\\Local\\Yarn\\Cache\\v4\\npm-object-assign-4.1.1-2109adc7965887cfc05cbbd442cac8bfbb360863\\node_modules\\object-assign\\package.json" to "C:\\work\\node_modules\\object-assign\\package.json".
verbose 4.147 Copying "C:\\Users\\jbloggs\\AppData\\Local\\Yarn\\Cache\\v4\\npm-object-assign-4.1.1-2109adc7965887cfc05cbbd442cac8bfbb360863\\node_modules\\object-assign\\readme.md" to "C:\\work\\node_modules\\object-assign\\readme.md".
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
info Direct dependencies
+- object-assign#4.1.1
info All dependencies
+- object-assign#4.1.1
Done in 3.86s.
What can I do to get create-react-app to invoke yarn in a way that yarn uses the registry config value?

I got same issue today and found the root cause, there is a piece of code checking for custom registry in yarn config. If not found then cached yarn.lock file (with links to default registry inside) is copied to target folder before install:
if (yarnUsesDefaultRegistry) {
fs.copySync(
require.resolve('./yarn.lock.cached'),
path.join(root, 'yarn.lock')
);
}
When you run the same install command from command line, then no conflict with generated lock file and all installs smoothly using your .npmrc. It was quite tricky to catch this as create-react-app clears lock file on failed install :).
I would consider this as create-react-app issue. Simple workaround is to set custom registry to yarn explicitly:
yarn config set registry http://myownregistry:1234 --global
Next create-react-app run will pick up this property and skip copying of cached lock file.

As far as I see, initial yarn installation of create-react-app doesn't accept/honor custom registry settings(Source code). But it does honor --verbose option(Source code).
You can create issue in official repo for custom registry support. There are some issues around this already(like this one). but, looks like this is a good to have feature.

Related

npm install throws ECONNRESET error but only for certain packages

I'm working behind a corporate proxy. I have npm configured like this:
$ npm config get
...
https_proxy = "http://proxy.my-domain.com:8080"
https-proxy = "http://proxy.my-domain.com:8080"
proxy = "http://proxy.my-domain.com:8080"
...
With these settings, I can install some packages fine, but not others. For example $ npm i react works perfectly fine, whereas installing #babel/core throws an ECONNRESET error.
$ npm i #babel/core
npm ERR! code ECONNRESET
npm ERR! syscall read
npm ERR! errno -54
npm ERR! network read ECONNRESET
...
Strangely, I'm able to install the package with yarn (which is configured for the proxy the same way npm is), but it too tells me that I have network issues (even though it successfully installs the package 🤔)
$ yarn add #babel/core
...
✨ Done in 2.99s.
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
I can't tell why it works with yarn, but not with npm. Here's what the npm debug log looks like:
73 silly tarball no local data for #jridgewell/sourcemap-codec#https://registry.npmjs.org/#jridgewell/sourcemap-codec/-/sourcemap-codec-1.4.14.tgz. Extracting by manifest.
74 silly tarball no local data for #jridgewell/trace-mapping#https://registry.npmjs.org/#jridgewell/trace-mapping/-/trace-mapping-0.3.17.tgz. Extracting by manifest.
75 silly tarball no local data for #jridgewell/set-array#https://registry.npmjs.org/#jridgewell/set-array/-/set-array-1.1.2.tgz. Extracting by manifest.
76 verbose stack Error: read ECONNRESET
76 verbose stack at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)
77 verbose cwd /Users/justinsmith/Dev/test-npm
78 verbose Darwin 21.4.0
79 verbose node v18.9.0
80 verbose npm v8.19.1
81 error code ECONNRESET
82 error syscall read
83 error errno -54
Anyone have any ideas why this is happening?
tl;dr adding this to my ~./npmrc provided a temporary fix:
# This is what I already had set
proxy=http://proxy.my-domain.com:8080/
https-proxy=http://proxy.my-domain.com:8080/
https_proxy=http://proxy.my-domain.com:8080/
# This is what I added
strict-ssl=false
registry=http://registry.npmjs.org/
maxsockets=3
This forces npm to make requests with http instead of https and limits the number of parallel requests to three.
One reason this works is because evidently the corporate proxy was scanning files for malware before forwarding them to the client. Evidently npm making too many requests in parallel over TLS overwhelms the malware scanner which eventually refuses some connections.
Yarn on the other hand will retry a couple of times whereas npm just throws an error and gives up.
A longer-term solution would be to get your IT department to add npm to a malware scanning exclusion list.
Full credit goes to this blog post, which provided these helpful solutions.

yarn create #scope/package references old version

I've been working on a npm/yarn create script which was once published under
#scopename/originalpackagename
After renaming the package name
#scopename/newpackagename
and removing the old package from npm registry I began getting an error when running
yarn create #scope/newpackagename somename
[1/4] Resolving packages...
verbose 0.174511263 Performing "GET" request to "https://registry.yarnpkg.com/#scope%2fnewpackagename".
verbose 0.385638523 Request "https://registry.yarnpkg.com/#scope%2fnewpackagename" finished with status code 200.
[2/4] Fetching packages...
verbose 0.396535904 Performing "GET" request to "https://registry.yarnpkg.com/#scope/originalpackagename/-/originalpackagename-1.4.0.tgz".
verbose 0.426215495 Error: https://registry.yarnpkg.com/#scope/originalpackagename/-/originalpackagename-1.4.0.tgz: Request failed "404 Not Found"
The issue was only tied to my local machine.
The problem was with the npm manifest located in my home directory.
~/.config/yarn/global/package.json
~/.config/yarn/global/yarn.lock
Which referenced the #scope/oldpackagename.
by removing the following files I was able to fix my problem.
rm ~/.config/yarn/global/package.json
rm ~/.config/yarn/global/yarn.lock

Can yarn be used to fetch packages from an on-prem Azure Artifacts repository?

We use on-prem Azure DevOps Server 2019.
In my project dir I have the following .yarnrc file:
C:\xyz\tip\ui\EngagementCommon.UI [master ≡ +3 ~1 -1 !]> cat .\.yarnrc
registry "http://tfsserver.xyz.com:8080/tfs/DefaultCollection/_packaging/platform_catalog/npm/registry/"
C:\xyz\tip\ui\EngagementCommon.UI [master ≡ +3 ~1 -1 !]>
Where platform_catalog is the name of the feed:
But when I run yarn I get this:
C:\xyz\tip\ui\EngagementCommon.UI [master ≡ +3 ~1 -1 !]> yarn
yarn install v1.22.0
[1/4] Resolving packages...
error Couldn't find package "#platform/catalog" on the "npm" registry.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
C:\xyz\tip\ui\EngagementCommon.UI [master ≡ +3 ~1 -1 !]> cat .\package.json|sls catalog
"#platform/catalog": "^1.0.71",
C:\xyz\tip\ui\EngagementCommon.UI [master ≡ +3 ~1 -1 !]>
As you can see on the image, the package is there on our Azure Artifacts npm feed, however yarn does not seem to inspect it at all, despite .yarnrc file asking to.
What am I missing?
EDIT 1
The --verbose flag helps to understand what is going on:
yarn --verbose
yarn install v1.22.0
verbose 0.1522596 Checking for configuration file "C:\\xyz\\tip\\UI\\EngagementCommon.UI\\.npmrc".
verbose 0.153013699 Found configuration file "C:\\xyz\\tip\\UI\\EngagementCommon.UI\\.npmrc".
verbose 0.154160399 Checking for configuration file "C:\\Users\\mkharitonov\\.npmrc".
verbose 0.15491 Found configuration file "C:\\Users\\mkharitonov\\.npmrc".
verbose 0.1557871 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 0.1565483 Checking for configuration file "C:\\xyz\\tip\\UI\\EngagementCommon.UI\\.npmrc".
verbose 0.157282799 Found configuration file "C:\\xyz\\tip\\UI\\EngagementCommon.UI\\.npmrc".
verbose 0.158124099 Checking for configuration file "C:\\xyz\\tip\\UI\\.npmrc".
verbose 0.158851699 Checking for configuration file "C:\\xyz\\tip\\.npmrc".
verbose 0.159633599 Checking for configuration file "C:\\xyz\\.npmrc".
verbose 0.1642738 Checking for configuration file "C:\\xyz\\tip\\UI\\EngagementCommon.UI\\.yarnrc".
verbose 0.1689344 Checking for configuration file "C:\\Users\\mkharitonov\\.yarnrc".
verbose 0.1744512 Found configuration file "C:\\Users\\mkharitonov\\.yarnrc".
verbose 0.175591399 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 0.1781605 Checking for configuration file "C:\\xyz\\tip\\UI\\EngagementCommon.UI\\.yarnrc".
verbose 0.1789498 Checking for configuration file "C:\\xyz\\tip\\UI\\.yarnrc".
verbose 0.1796986 Checking for configuration file "C:\\xyz\\tip\\.yarnrc".
verbose 0.1804712 Checking for configuration file "C:\\xyz\\.yarnrc".
verbose 0.1856058 current time: 2020-02-20T15:19:28.047Z
[1/4] Resolving packages...
verbose 0.268615799 Performing "GET" request to "http://tfsserver.xyz.com:8080/tfs/DefaultCollection/_packaging/platform_catalog/npm/registry/#platform%2fcatalog".
verbose 0.2893787 Request "http://tfsserver.xyz.com:8080/tfs/DefaultCollection/_packaging/platform_catalog/npm/registry/#platform%2fcatalog" finished with status code 401.
verbose 0.3031119 Error: Couldn't find package "#platform/catalog" on the "npm" registry.
at MessageError.ExtendableBuiltin (C:\Program Files (x86)\Yarn\lib\cli.js:721:66)
at new MessageError (C:\Program Files (x86)\Yarn\lib\cli.js:750:123)
at NpmResolver.<anonymous> (C:\Program Files (x86)\Yarn\lib\cli.js:50302:15)
at Generator.next (<anonymous>)
at step (C:\Program Files (x86)\Yarn\lib\cli.js:310:30)
at C:\Program Files (x86)\Yarn\lib\cli.js:321:13
at processTicksAndRejections (internal/process/task_queues.js:85:5)
error Couldn't find package "#platform/catalog" on the "npm" registry.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Yarn gets 401 talking to the custom repository, but it silently swallows it and proceeds to check the package in the npm, where it certainly does not exist. The fact that yarn does not surface 401 is a usability issue, I think.
Can yarn be used to fetch packages from an on-prem Azure Artifacts
repository?
Answer this question, don't worry, TFS support yarn to consume the artifacts.
The error message more relevant with yarn itself.
Here some troubleshooting method you can try:
1) Whether it has any network issues, e.g Firewall and etc.
2) Confirm that there's no different registry set for any of .yarnrc or .npmrc files.
If the issue still occurred after above checked, you can add --verbose to command to get detailed execution log and analyze it.

"Already up-to-date" and "Run 'yarn' to install missing dependencies"?

I've got a bit of a weird situation where "ember s" reports "Missing yarn packages" followed by a list of missing packages (two of them) and then "Run 'yarn' to install missing dependencies".
However when I run 'yarn' I get the message "success Already up-to-date" .
Any ideas how to get out of this circle ?
There's something I did immediately before this started which I guess is the source of my problem
Getting rid of an Add-on
I had installed an Ember Add-on which had generated problems so I decided to get rid of it . To do that I did the following :
git push -f origin 913c2dee12b0363df0664c9c63e0443abe0adb57:foo-bar
git reset --hard 913c2dee12b0363df0664c9c63e0443abe0adb57
yarn
yarn install
yarn clean
yarn install
yarn
Where 913c2dee12b0363df0664c9c63e0443abe0adb57 was the last commit before the unwanted add-on was installed. I don't think there was anything wrong in doing that but now I'm wondering.
Output of running Ember Server
When I run 'ember s' I get this output ...
DEPRECATION: ember-cli-babel 5.x has been deprecated. Please upgrade to at least ember-cli-babel 6.6. Version 5.2.8 located: foobar -> ember-cli-build-date -> ember-cli-babel
Missing yarn packages:
Package: #bower_components/jquery
* Specified: jquery/jquery-dist#
* Installed: (not installed)
Package: #bower_components/jstree
* Specified: vakata/jstree#^3.3.5
* Installed: (not installed)
Run `yarn` to install missing dependencies.
Stack Trace and Error Report: /tmp/error.dump.33c6e8c0abc9fc8abd355dc080268f9c.log
An error occurred in the constructor for ember-cli-dependency-checker at /media/mint/dev/foobar/node_modules/ember-cli-dependency-checker
Warning about ember-cli versions
I don't think this is relevant but just for completeness
Running the 'yarn' results in the following appearing in the output text ...
warning foobar#0.0.0: "dependencies" has dependency "ember-cli" with range "~3.8.1" that collides with a dependency in "devDependencies" of the same name with version "3.8"
EDIT: OK I was able to resolve this with the help of the comment by dwenzel ...
rm -rf node_modules && yarn
Although that actually led into a different issue which I'm almost certain was unrelated but I'll just mention it here in case it's useful to those who come after.
The execution of yarn initially failed with the following error ...
35238 verbose stack Error: node-sass#4.5.3 postinstall: `node scripts/build.js`
35238 verbose stack Exit status 1
35238 verbose stack at EventEmitter.<anonymous> (/home/rshea/.nvm/versions/node/v10.15.3/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:301:16)
35238 verbose stack at EventEmitter.emit (events.js:189:13)
35238 verbose stack at ChildProcess.<anonymous> (/home/rshea/.nvm/versions/node/v10.15.3/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
35238 verbose stack at ChildProcess.emit (events.js:189:13)
35238 verbose stack at maybeClose (internal/child_process.js:970:16)
35238 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)
35239 verbose pkgid node-sass#4.5.3
35240 verbose cwd /media/mintextra/dev/ddn-build-test-temp/foobar
35241 verbose Linux 3.13.0-169-generic
35242 verbose argv "/home/rshea/.nvm/versions/node/v10.15.3/bin/node" "/home/rshea/.nvm/versions/node/v10.15.3/bin/npm" "install"
35243 verbose node v10.15.3
35244 verbose npm v6.4.1
35245 error code ELIFECYCLE
35246 error errno 1
35247 error node-sass#4.5.3 postinstall: `node scripts/build.js`
35247 error Exit status 1
35248 error Failed at the node-sass#4.5.3 postinstall script.
35248 error This is probably not a problem with npm. There is likely additional logging output above.
35249 verbose exit [ 1, true ]
I was able to resolve that with ...
npm install node-sass#latest
npm install
... at which point ember s was able to run without errors.
It looks like you want to do yarn install --check-files to verify that the files have not been removed from node_modules. This avoids having to wipe out your node_modules file which can be time consuming.
https://classic.yarnpkg.com/en/docs/cli/install/#toc-yarn-install-check-files
https://github.com/yarnpkg/yarn/issues/2240
When yarn gets confused like this, you can usually fix things up by clearing out your node modules before installing:
rm -rf node_modules && yarn
The way I managed to get around this without deleting the entire node_modules directory was just to remove the module from topLevelPatterns within node_modules/.yarn-integrity.
Disclaimer: I don't know what the implications of this are but yarn's integrity was already questionable and it works so meh!?
You may also try to reinstall/download all packages with:
yarn install --force

Unable to install NPM packages due to path length constraint using NPM 5.X

I'm running Windows 10, NPM v5.5.1, and node v8.9.1.
Edit: I have since updated to node v8.9.4 and npm v5.6.0. The problem remains unchanged.
I set up my development environment on this machine about 2 months ago. I'm using Angular CLI to build my client apps.
Everything was going fine. I added a few packages via NPM without a problem, such as Gulp and ngx-bootstrap. Then I started to run into errors on some of my package installs.
The errors are:
npm ERR! code PATH_LENGTH_EXCEEDED
npm ERR! errno PATH_LENGTH_EXCEEDED
npm ERR! request to https://registry/npmjs.org/{{package}} failed, reason: path length constraint exceeded
npm ERR! A complete log of this run can be found in:
npm ERR! {{npm_cache path}}\_logs\2018-02-08T14_43_40_856Z-debug.log
The contents of that log file are:
0 info it worked if it ends with ok
1 verbose cli [ 'C:\\Program Files\\nodejs\\node.exe',
1 verbose cli 'C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli 'install',
1 verbose cli 'ngx-cookie-service',
1 verbose cli '--save' ]
2 info using npm#5.5.1
3 info using node#v8.9.1
4 verbose npm-session d55be12849534a0a
5 silly install loadCurrentTree
6 silly install readLocalPackageData
7 silly fetchPackageMetaData error for ngx-cookie-service#latest request to https://registry.npmjs.org/ngx-cookie-service failed, reason: path length constraint exceeded
8 verbose type system
9 verbose stack FetchError: request to https://registry.npmjs.org/ngx-cookie-service failed, reason: path length constraint exceeded
9 verbose stack at ClientRequest.req.on.err (C:\Program Files\nodejs\node_modules\npm\node_modules\pacote\node_modules\make-fetch-happen\node_modules\node-fetch-npm\src\index.js:68:14)
9 verbose stack at emitOne (events.js:116:13)
9 verbose stack at ClientRequest.emit (events.js:211:7)
9 verbose stack at TLSSocket.socketErrorListener (_http_client.js:387:9)
9 verbose stack at emitOne (events.js:116:13)
9 verbose stack at TLSSocket.emit (events.js:211:7)
9 verbose stack at emitErrorNT (internal/streams/destroy.js:64:8)
9 verbose stack at _combinedTickCallback (internal/process/next_tick.js:138:11)
9 verbose stack at process._tickCallback (internal/process/next_tick.js:180:9)
10 verbose cwd C:\Development\test
11 verbose Windows_NT 10.0.15063
12 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "ngx-cookie-service" "--save"
13 verbose node v8.9.1
14 verbose npm v5.5.1
15 error code PATH_LENGTH_EXCEEDED
16 error errno PATH_LENGTH_EXCEEDED
17 error request to https://registry.npmjs.org/ngx-cookie-service failed, reason: path length constraint exceeded
18 verbose exit [ 1, true ]
I researched this, and found the Windows 10 file path 260 character limitation. I thought that npm version 3.1.0 should have fixed this issue, but I decided to followed the instructions in this answer, because I'm still running into this issue despite using NPM v5.5.1.
I found that my version of Windows was prior to the roll out of the feature that lets you disable this limitation. I updated to Version 1703 (OS Build 15063.483), and to enable Win32 long paths.
Yet I'm still getting the error, and unable to install a variety of npm packages.
In testing to see if it was an issue with packages that have a lot of dependencies, I tried installing or reinstalling a couple of other packages.
Some fail with the errors above. Others succeed with the following warnings:
npm WARN Unexepcted warming for https://registry.npmjs.org/: Miscellaneous Warning PATH_LENGTH_EXCEEDED: request to https://registry.npmjs.org/{{package name}} failed, reason: path length constraint exceeded
npm WARN Using stale package data from https://registry.npmjs.org/ due to a request error during validation
Packages throwing the error include:
jslint
ngx-cookie-service
chart.js
angular-cli
Packages that throw the warnings include:
font-awesome
#angular/cli
moment
ngx-bootstrap
bootstrap
jasmine
I suspect that something has changed, either in a policy on my workstation, or in our network security, that is causing this. All of the packages that succeed seem to be packages that I had previously installed, either as a direct install, or as a dependency of #angular/cli (one of the first packages I installed). I'm assuming that the stale package data warning indicates that whatever problem I have with the path length is preventing updated data being retrieved, and therefore npm is falling back to cached data from previous installations of the selected package and its dependencies.
So now I'm stumped as to how to diagnose exactly where the issue is happening. If its a security policy that changed, then I need to be able to describe exactly what is being blocked so that I can work with our security department to fix this. But the only information I can find about the PATH_LENGTH_EXCEEDED errors lead me to old information about versions of npm prior to 3.1.0.
How can I identify the source of this problem?
After additional searching, I found references to path length exceeded with regards to SSL/TLS certificate authorities. I tested this issue by changing the npm registry to use http instead of https (note: this is a temporary step only; I have turned https back on once I verified the issue):
npm config set registry http://registry.npmjs.org/
This allowed me to install the problematic packages.
It seems the underlying cause is SSL Inspection performed by our network security team. The decryption, inspection, and re-encryption process, and subsequent changes in the Issuing Authority on the certificate, apparently triggers this error.