package.json build issue for shared lib

[sbuys]

Not sure if this is a problem on Firebase side or some nx config, but after being able to deploy functions with a shared library I'm now gettings this error message in the Firebase logs:

Build failed: npm ERR! cipm can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with npm install before continuing

[edbzn]

Same here, it is working with the local emulator but when I deploy into Firebase then I get an error due to the shared lib import:

Detailed stack trace: Error: Cannot find module '@org/my-pkg'

In the generated dist folder, the dependency @org/my-pkg is present in the node_modules, so my assumption is that Firebase is just ignoring the content of the node_modules and trying to rebuild the dependencies so the shared lib is deleted.

[sbuys]

In our case, we were able to fix by modifying the predeploy entry in firebase.[APP_NAME].json to: npx nx build [APP_NAME] --with-deps && cd dist/apps/[APP_NAME] && npm install

The addition of npm install generates package-lock.json locally and sidesteps what appears to be a package.json and package-lock.json mismatch when generated on the GCP side.

This seems like an okay temporary workaround, though I'd like to know why GCP is generating a conflicting lock file during the build.

[edbzn]

I tried, but cannot get it working, here is what I get in return:

i  functions: preparing codebase default for deployment

Error: Failed to load function definition from source: Failed to generate manifest from function source: Error: Cannot find module '@org/my-pkg'

As a dirty fix, I inlined the lib into the Firebase app. Would be interested in a reliable solution @simondotm.

[simondotm]

@sbuys solution seems to be the only way this works now for projects that import buildable libraries - ie. it is necessary to use a v5+ of npm and run npm i in the functions dir prior to deploy otherwise I'm seeing Error: Error parsing triggers: Cannot find module '@myorg/nodelib3' type errors from the Firebase CLI.

This is unpleasant as it increases deployment time.

I dont understand why this is necessary - for deployments with no buildable library imports, firebase tools deploys fine. Only when a local dependency is added with "@myorg/nodelib3": "file:libs/nodelib3" does this become an issue, and this is exactly what the firebase docs say is supported.

I'm using firebase tools version 11.16.1

[simondotm]

I've tried running npm pack on the imported libraries so the dependency is "@myorg/nodelib3": "file:@myorg-nodelib3-0.0.1.tgz" instead, but same issue

[simondotm]

I'm wondering if the firebase CLI is somehow delegating to the root workspace node_modules and package.lock and doesn't find @myorg/nodelib3 in there (which is correct), so it bails

[simondotm]

This is the code in firebase-tools https://github.com/firebase/firebase-tools/blob/54a3f85534f4d42129c1e49f74eea78e2872ef97/src/deploy/functions/runtimes/node/triggerParser.js

I'm wondering if its time to move to es modules instead of commonjs. Or just bundle functions with rollup to side step this whole issue now.

[simondotm]

Sorry folks, ignore all of my above comments, I'm an idiot. My issue was caused by something unrelated.

[ciriousjoker]

Maybe this helps someone (probably me in the future!):

I'm using the suggested workaround from here and here in combination with this of running this in the predeploy scripts like this:

npx nx build appname --with-deps && cd dist/apps/appname && npm install --package-lock-only

After the build command npx nx build appname --with-deps, there's now a dist/apps/appname folder with a package.json file and a node_modules/@myorg/shared package.

Running npm install [--package-lock-only] will see the folder in node_modules, so the resulting package-lock.json will contain this section:

    "node_modules/@myorg/shared": {
      "version": "0.0.0"
    },

Now, when I delete node_modules/ and run npm ci (which is what happens during cloud function deployment!), it will fail because the local dependency couldn't be resolved.

Workaround:

If I do this instead:

• npx nx build appname --with-deps
• cd dist/apps/appname
• rm -rf node_modules or npx rmdir-cli node_modules/ <-- please tell me if theres a better cross platform folder delete!
• npm install

I end up with this portion in the package-lock.json file:

    "node_modules/@myorg/shared": {
      "version": "0.0.0",
      "resolved": "file:libs/shared"
    },

Everything else in the file is identical.

Now npm ci works.

We went back to using the default behavior (ie without the suggested workaround of running npm install during predeploy), but perhaps this is useful to someone who requires a package-lock.json or runs into other issues.

Versions:

• package-lock.json lockfileVersion: 3
• npm: 9.3.0
• nx-firebase: 0.3.4
• firebase-tools: 11.17.0 <-- yes, there's 11.19.0 available, but that one is a bit broken right now

[simondotm]

Thanks for the detailed info @ciriousjoker - I'd like to get to the root of this issue as I am able to deploy fine without needing to generate a package-lock file, but there are a ton of variables - nx version, plugin version, firebase cli versions, node versions etc.

[ciriousjoker]

Deployment does work fine without a package lock json. I just originally did the npm install workaround because of another issue and npm install breaks deployment because of the wrong package lock.

Now I fixed the other issue and deployment without any additional npm install works fine. Let's hope it stays that way.

[simondotm]

closing this, can re-open if anyone else sees the issue again.