Error: Cannot find module 'functions-have-names' -v1.5.1

[akan]

failed to load config from /app/vite.config.ts
error during build:
Error: Cannot find module 'functions-have-names'
Require stack:

• /app/node_modules/set-function-name/index.js
• /app/node_modules/regexp.prototype.flags/implementation.js
• /app/node_modules/regexp.prototype.flags/index.js
• /app/node_modules/deep-equal/index.js
• /app/node_modules/vite-plugin-pages/dist/index.js
• /app/vite.config.ts
• /app/node_modules/vite/dist/node/chunks/dep-ca21228b.js
  at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
  at Function.Module._load (node:internal/modules/cjs/loader:778:27)
  at Module.require (node:internal/modules/cjs/loader:1005:19)
  at require (node:internal/modules/cjs/helpers:102:18)
  at Object. (/app/node_modules/set-function-name/index.js:5:38)
  at Module._compile (node:internal/modules/cjs/loader:1103:14)
  at Module._extensions..js (node:internal/modules/cjs/loader:1157:10)
  at Object._require.extensions. [as .js] (file:///app/node_modules/vite/dist/node/chunks/dep-ca21228b.js:62359:17)
  at Module.load (node:internal/modules/cjs/loader:981:32)
  at Function.Module._load (node:internal/modules/cjs/loader:822:12)
  Build step 'Execute shell' marked build as failure

[regnete]

Same issue here.
As a workarround add the follwing to your package.json:

"overrides": {
    "deep-equal": {
      "regexp.prototype.flags": "npm:regexp.prototype.flags@1.5.0"
    }
  }

[MaisiKoleni]

Root of the problem seems to be this issue in the set-function-name dependency: ljharb/set-function-name#1

[futin]

You guys have 30 million downloads per week (great job btw!) and still you published a major update of some small library without testing. Please try not to do this in the future, as your "regex" library is being used by deep-equal and this library is also used by a lot of apps.

[sigmama]

same issue here that result in unusable docker image....
May be related to the package is put in devDependency and could be removed during production builds?

[vladislavkorenik]

Adding "functions-have-names": "^1.2.3" to my devDependities resolved this.

[vladislavkorenik]

FYI: set-function-name (which was used instead of function-have-names in this lib) uses functions-have-names but does not have it in its dependencies.

@ljharb SO pls try add functions-have-names to the package.json dependencies (instead of having it in devDependencies) to fix it

[glenstaes]

This change caused our internal libraries to fail overnight because it's a dependency of a dependency of a dependency of ...

We opted for the overrides solution as suggested by @regnete, which works fine!

Same issue here. As a workarround add the follwing to your package.json:

"overrides": {
    "deep-equal": {
      "regexp.prototype.flags": "npm:regexp.prototype.flags@1.5.0"
    }
  }

[Blackbaud-SteveBrush]

We have 100s of applications failing their ng lint step because of the missing dependency. I can't update every package.json with the overrides workaround. Possible to incorporate the fix in regexp.prototype.flags instead?

[ljharb]

v2.0.1 of set-function-name should fix this issue.

I'd suggest using lockfiles so this kind of thing isn't so urgent.

[glenstaes]

v2.0.1 of set-function-name should fix this issue.

I'd suggest using lockfiles so this kind of thing isn't so urgent.

We do use lockfiles, but if dependencies are defined with a ^ or ~ and a package releases a new version as a patch (1.5.0 -> 1.5.1), it is automatically downloaded during npm install. Very often, lockfiles get updated or regenerated.

This was very confusing to us because our pipeline was working fine, but a developer that had added a new dependency and fully regenerated the lockfile, suddenly had linting not working (which is unrelated to the added dependency).

[ljharb]

@glenstaes totally understand that, but surely that developer was thus prevented from merging their code, affecting nobody but them?

[jkrauss82]

We have a process where we let one of our pipelines build a package which is then downloaded by our workers and installed via npm. This fails, even though we do have a package-lock.json and a npm-shrinkwrap.json, as npm seems to use the package.json from inside the package, even though npm-shrinkwrap.json exists.

I do not think using a package-lock.json will prevent failures to occur in such cases for everyone.

[ljharb]

It would be a major bug in npm if an npm-shrinkwrap.json was not respected; please file that if that's the case, since it's worked for the entirety of npm's existence.

The lockfile that would protect you is the package-lock in the project in which "installed via npm" happens.

[glenstaes]

@glenstaes totally understand that, but surely that developer was thus prevented from merging their code, affecting nobody but them?

Sure, but if you have 6 developers at the beginning of a project, all adding dependencies and spending an hour investigating why they can't run the linting command, this easily adds up to 6 hours of budget getting lost. Add to this, a senior developer that is capable of identifying from where this issue originates and to ensure that all 6 developers are up and running again, this becomes a very costly effort, very fast. And that just for one company. With 30 million downloads per week, many companies are affected.

[ljharb]

Gotcha - sounds like my unpaid work is saving many companies a lot of money (most of the time). I wonder what could be done about that :-p

[jkrauss82]

It would be a major bug in npm if an npm-shrinkwrap.json was not respected; please file that if that's the case, since it's worked for the entirety of npm's existence.

The lockfile that would protect you is the package-lock in the project in which "installed via npm" happens.

Thanks for the quick response.

I think I am not sound enough with the whole npm environment. We do not have a package-lock.json on the workers, just a package.json which has our package as the single dependency. We then just install our previously built package which in turn requires its dependencies, leading to v1.5.1 of regexp.prototype.flags being installed, even though the npm-shrinkwrap.json included in the built package specifies a different version. But I think I am missing something here.

[ljharb]

The workers should have lockfiles, which should be in source control and whose changes should be reviewed by developers. That way, nothing unexpected should arrive on your workers.

[mstrucken]

The workers should have lockfiles, which should be in source control and whose changes should be reviewed by developers. That way, nothing unexpected should arrive on your workers.

@ljharb how do you handle for example a small CLI tool, which you publish as a npm package on your self-hosted GitLab and which you want to install on all your servers? For sure you commit a package.json and a package-lock.json in that project. Even a npm-shrinkwrap.json. But on the server you only have your .npmrc containing the credentials for your self-host GitLab and then you just run npm install @your-registry/your-cli-tool and by doing so the npm-shrinkwrap.json is ignored and the dependencies of your CLI tool get only installed according to the package.json of your CLI tool.

[ljharb]

You should have a package.json and a package-lock.json on each server. or, better, that should all be one project that's tarballed into an artifact and deployed to all your servers, so that you're not doing any installations directly inside a server.