“Cannot read property 'match' of undefined” during Npm install

Question

I encountered error during building Jenkins

Jenkins Log

Task :api:processResources Task :api:classes Task :web:node

Answer 1

Try removing your package-lock.json to see if that helps.

rm -rf package-lock.json 

Answer 2

You have to remove project Package-lock.json file. then try to install what you want.

Answer 3

The error may vary on what npm internals file it can be thrown! (And i wonder for all the possible reasons)! And it should be a bug!

(in my last case: it was on [_canPlaceDep] method of the file build-ideal-tree.js of npm!

Note

If none of the common methods works! And that you are using nodejs v15+ and one of latest npm version! Go to the last part! The problem that i call the nodejs VERSIONS HELL! (NOTE: after reflection! For npm it may not be a version HELL! READ TO KNOW)

How to try to solve

Removing node_modules

\rm -r node_modules

Reinstall after

npm install

(NOTICE: that may still not work)

You can try to remove package.lock too!

Clearing the cache

npm cache clean --force

That can work if the cache get currupted somehow! But the common error is more of Unexpected end of JSON input while parsing near ...

You can check my answer here (that explain it well): https://stackoverflow.com/a/52249619/7668448

Removing package.lock (which is not adviced)

rm package.lock

Why not advised

From @DanielIM comment

No, it should not. This is "the recommended workaround" but is incredibly broken in practice. Having a locked dependency in package.json in no way ensures that dependency's dependencies will remain consistent, so removing the package-lock.json file, npm installing, and generating a newlock file *will allow those sub-dependencies to change, which often completely breaks any future building. Using an existing lock file is often the only way to maintain builds (that is the POINT of the file, after all) so removing it completely goes against the reason for its existence.

So generally it's nice to leave that as a last resort! If it does not work ! You can try with removing node_modules too!

Reinstalling nodejs or NPM

A problem can happen at npm level! Trying to reinstall can be a nice way!

To test quickly in place of reinstalling! Using NVM (nodejs version manager) and switching to another version is fast and interesting! Because we can also test for VERSION HELL PROBLEM!

If it works after switch! Then either it's a problem with npm and a reinstallation may fix it! Or it's a version Hell problem (a bug)!

How to reinstall fast! Again use nvm!

nvm uninstall v15

then

nvm install v15

then use it

nvm use v15

You can just install another version and use it! (v14 for example)

Check the VERSION HELL PROBLEM And how to use nvm to switch between versions!

The uncommon or new! THE VERSIONS HELL

In this year! I encountered many nodejs VERSIONS HELL problems! (I like to call them that) (because i gave them a name! The skies are blessing me with more) (irony)

To list them quickly:

• Node v14 HELL (POSTGRES) and causing problem for pg module (postgres) [because of breaking changes! That pg was depending on!] (if you are using knex or any orm or query builder! And use it with postgres! Big chance you'll encounter it! If you just upgrade nodejs version alone! [Solution: upgrade pg versoin to the latest (>=8.0.3) [They made a fix] (Can check a full detailed explanation here https://stackoverflow.com/a/64639717/7668448)]
• Typescript v4 HELL! A similar problem! Where typescript in one of my project fail internally with cannot read property "" of undefined! Rolling back to v3.9 run successfully! No problem!

Fix Our problem (Cannot read property 'matches' of undefined)

If you are using node v15! Try with node v14 (npm v6.14.8)! That may be it! An npm bug! That's a first thought can be! That what i thought at first!

That's was the case for me! In this last problem! I tried all the solutions that i'm familiar with! And they were already listed here too! None worked! And more when i removed node_modules! I was Please not another version HELL! And yea it was exactly that! It worked well with **node v14** (npm v6.14.8). Which suggest a [BUG].

Then reflecting a bit on it! It was like hey! When i change the version! I'm using another nodejs installation! Which can just not have the problem. A problem with npm structure or something and a re-installation may fix it (as mentioned above)!

After it ! I tried with node v15.3.0. And it worked all ok! After the installation was all right done! I went back to node v15.0.1! And it worked again! So the problem is absolutely not a VERSION HELL problem

I'm still uncapable to explain what did happen! But in short! Using NVM! To try with another version! Is a good way to go about it! You can reinstall quickly the current version too!

Big Take down (for the VERSION HELL)

Starting from nodejs v14! And v15! Or just generally! It's nice to be skeptical about the versions! More of a reason when it doesn't make sense! And that's about all the problems not just npm! There is so many VERSIONS HELL problems! I encountred 2 up to now! Being alerted to the VERSIONS HELL can save you a lot of time!

How to test fast and also switch nodejs version quickly

To be fast at testing this and checking! Mostly for any internal error that will come! I'll google it quickly! And try another version of nodejs or whatever in question (ex: typescript)! I can too debug (console.log) The internal file where the error was thrown! And try to figure out something!

But that's it! It's really interesting to check for other versions! (nodejs, typescript, ... [remember be skeptical or alerted])

For nodejs To do it quickly:

NVM to switch quickly nodejs versions (npm)

Use NVM (nvm is a version manager for node.js,)

Quick installation of version in NVM

nvm install v14

Quick switch to another node version

nvm use v14

(Check the doc for the details! And installation process)

For switching and testing some npm module version (ex: typescript)

If it's a cli tool! you can install a precise version globaly

npm i -g typescript@3.9

use the @ syntax!

Once you verify and test you can switch back to whatever you like!

If it's in a project! You can do the same (not globally)! use the @ syntax to precise the version!

npm i moduleName@<versionSpecifier>

or with saving

npm i moduleName@<versionSpecifier> --save

Version specifier use SEMVER convention (https://semver.org/).

Last tip (use npx in your scripts)

It's nice to set a version internal to the project! For example

"devDependencies": {
    "@types/cors": "^2.8.6",
    "@types/gulp": "^4.0.6",
    "cross-env": "^6.0.3",
    "glob": "^7.1.6",
    "gulp": "^4.0.2",
    "nodemon": "^2.0.4",
    "ts-node": "^8.10.2",
    "typescript": "^3.9.7", // <===== Typescript version 3.9 (for this project)
    "jest": "^26.6.3"
  }

In scripts i use npx:

"scripts": {
    "build": "npx tsc && gulp build",

When we use npx this way with a nodjes module cli tool! npx will check first if the module is available in the local node_modules! If found will use it (use global otherwise, or Download latest and run)!

So doing what i'm suggesting! Will make sure your project will run independently from whatever you have in global!

(Read more about npx if you don't know the tool well)

Answer 4

You have to remove both package-lock.json and node_modules/.

If you don't remove both, the problem will come back on the next npm install.

Answer 5

I had the same error when running npm install in my repo. I don't use Jenkins, but I found a generic approach to debugging (and ultimately resolving) this issue in NPM.

1. Open the npm debug log file that the cli provides you. (on Windows, under C:\Users\USERNAME\AppData\Roaming\npm-cache\_logs by default)
2. Look for the stack trace of the error, at the bottom of the file.
3. The first three lines of the error stack trace should be something like:

18 verbose stack TypeError: Cannot read property 'match' of undefined
18 verbose stack     at tarballToVersion (C:\Users\USERNAME\AppData\Roaming\nvm\v14.5.0\node_modules\npm\lib\install\inflate-shrinkwrap.js:87:20)
18 verbose stack     at inflatableChild (C:\Users\USERNAME\AppData\Roaming\nvm\v14.5.0\node_modules\npm\lib\install\inflate-shrinkwrap.js:113:22)

4. Open up the inflate-shrinkwrap.js file, and go to the line listed in stack-trace line #3 above.
5. Add this debugging code: (just before the line [in stack-trace] which calls tarballToVersion)

if (sw.version == null) {
    console.error(`
        NPM is trying to retrieve package "${name}" with version "undefined"!
        Package location: ${(onDiskChild || {}).location}
        Package parse error:`, (onDiskChild || {}).error);
}

6. Run npm install (or whatever command yields the error). You should see an output like this:

        NPM is trying to retrieve package with version "undefined"!
        Package location: /firebase-feedback/webpack-dev-middleware
        Package parse error: [Error: ENOENT: no such file or directory, open 'C:\Root\Apps\@V\@Modules\firebase-feedback\Main\node_modules\webpack-dev-middleware\package.json'] {
  errno: -4058,
  code: 'ENOENT',
  syscall: 'open',
  path: 'C:\\Root\\Apps\\@V\\@Modules\\firebase-feedback\\Main\\node_modules\\webpack-dev-middleware\\package.json'
}

7. Go to the path specified in the internal error. You should find that the package.json file at that path is indeed missing.
8. Resolve that underlying "package.json" issue as you see fit. (for me, this was by deleting the C:/Root/Apps/@V/@Modules/firebase-feedback/Main/node_modules folder, then running npm install in the Main folder)

---

Note that in my case, the underlying issue (of the missing package.json file) appears to have been caused by me accidentally running npm install from the parent project (which uses my firebase-feedback library), while I had that library "npm linked".

I normally use npm-safe-install to avoid these sorts of issues (when using npm link), but I must have forgotten sometime recently -- leading to NPM mangling the npm-linked libraries' node_modules folders.

Similar issues relating to npm link have happened before, but I hoped NPM would have patched these sorts of issues by now. Apparently not; though version 7 of NPM has been stated as going to have a rewrite in that area, so hopefully that will solve it long term.