Lock file reported as out of sync in firebase build

[petr166]

Hi, i'm trying to get away from manually copying local dependencies in a firebase functions monorepo and came across this tool which seems to abstract away the work really nicely, thanks for your efforts 👍.

My issue is that copying the lock file in isolate makes the firebase build fail with the following message.

npm ERR! `npm ci` 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.

I tried doing a clean install with no luck. Is this something you can help with? For now, i have it working with the excludeLockfile flag on, but would like to steer away as the deps tree grows.

My environment (created lock file here, and matched it in gcp build)

❯ node -v
v16.19.1
❯ npm -v
8.19.4

[0x80]

In my (very limited) testing, the npm and yarn lockfiles could just be deployed as-is. But of course the lockfile needs to be up to date before you start the isolate process.

Are you sure the lockfile is up to date? Maybe run an npm install to be sure or try deleting the lockfile and generating it again.

There should be no reason to manually copy anything to the isolate directory. If you have "excludeLockfile" set to false (or not have the setting at all) the lockfile is already copied as-is.

You are using old versions of node and npm though, so you might want to try upgrading if possible. Node 16 is already being deprecated soon by some platforms (like Vercel)

[0x80]

Hi @petr166 today I tested more with NPM as part of the work for #15 and I ran into the issue you described.

So apparently I never tested it properly with NPM lockfiles. I haven't yet found a solution, and the error seems to be misleading as the lockfile is definitely available.

For now, lockfiles are supported for Yarn v1 and v3, so if it is an option for you to switch and you really find lockfiles important maybe that's worth considering...

[0x80]

@petr166 how did you match the version in gcp build?

I realize now that my error was different, and it might be because I'm using node 18.... In my case npm ci is complaining that there is not lockfile, yet when I download the uploaded functions source bundle it is all ok, and I can run npm ci in it without issues.

[0x80]

It looks like I've found a solution for Node 18. The isolate process now copies the .npmrc file from the root of the monorepo. If I generate a new lockfile with Node 18 and deploy to runtime node18 it works.

The fix will be included in v1.2.0 but you can start using the release candidate (rc3) already via @next

[0x80]

Unfortunately I couldn't reproduce it reliably with NPM after all. I have seen deploys succeed but after that I couldn't make it work anymore.

I think there might be something odd going on in the Firebase build pipeline. I'm giving up for now.

[petr166]

Thanks for the info, i'm gonna try again now with the latest version. It's true maybe the older node version is problematic but i'm stuck with it at least for now 😅.

[petr166]

@petr166 how did you match the version in gcp build?

I realize now that my error was different, and it might be because I'm using node 18.... In my case npm ci is complaining that there is not lockfile, yet when I download the uploaded functions source bundle it is all ok, and I can run npm ci in it without issues.

i use engines key in package.json

  "engines": {
    "node": "16",
    "npm": "^8.19.4"
  },

[petr166]

The issue persists with "isolate-package": "^1.3.1". I'm gonna stick with excluding the lock file for now (as otherwise it works wonders) and maybe investigate this case a bit deeper when i get the time. Thanks @0x80 for support! 💪

[0x80]

@petr166 Happy to report that lockfile output is now supported for all package managers, with a fallback to NPM when necessary. See lockfiles for more info

[petr166]

I can confirm that it works great with isolate-package@1.9.4. Thanks again @0x80, solid effort!

I had to add @google-cloud/functions-framework dependency in packages/firebase after getting an error in the beginning, so maybe this could be mentioned in the documentation 🤔.

[petr166]

Oh btw I changed my setup since creating this issue, currently using pnpm

❯ node -v
v20.9.0
❯ pnpm -v
8.12.1

[0x80]

@petr166 Great to hear! The dependency should be mentioned in the documentation somewhere but I'll see if I can make it more apparent. Weirdly the dependency is only required if you deploy a PNPM workspace.

Note that there's now also an option forceNpm which will output a package-lock.json file, and declares NPM to be the packageManager, even if your monorepo is Yarn or PNPM. The versions should match the original lockfile, so for the deployment it shouldn't matter. I have added it in case you want to deploy to a platform that doesn't support your package manager.