Why does firebase functions not respect existing lockfiles?

[steebchen]

Related issues

[REQUIRED] Version info

node: v16.20.0

firebase-functions: 9.16.0

firebase-tools: 12.4.0

firebase-admin: 11.8.0

[REQUIRED] Test case

When I do a npx firebase deploy, there seems to be a separate project being created for firebase functions in .firebase/<project-id>/package.json. The problem is that the package-lock.json from the root project is not respected, as there are a bunch of packages being added, and the package-lock.json is regenerated from scratch for that project in .firebase.

I am actually running in a caveat (at least I believe this is because of that) where a subdependency results in a bug, which only happens on firebase functions, and not on Vercel or anywhere else (as Vercel respects the lockfile and just runs the NextJS server).

I'm wondering if there's any way to make the original lockfile being respected. My way of solving this would be to just use Cloud Run via a Dockerfile which runs next start, but I'm really wondering how to make it work with firebase functions and how other people deal with this or if they were just lucky enough to not ever run into a case where a subdependency is slightly different and thus creating issues.

[REQUIRED] Steps to reproduce

• initialize any firebase project
• see a new package.json created in .firebase/<project-id>/package.json without a lockfile, then shorty after a lockfile is created at .firebase/<project-id>/package-lock.json.

[REQUIRED] Expected behavior

No new package.json and lockfile is created and versions are deployed exactly as they are defined in the project root lockfile.

[REQUIRED] Actual behavior

see above

Were you able to successfully deploy your functions?

Yes.

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not have all the information required by the template. Looks like you forgot to fill out some sections. Please update the issue with more information.

[blidd-google]

Hi @steebchen, from the context you provided, it sounds like you are trying to deploy a NextJS server using Firebase services. Firebase has a feature called Web Frameworks that allows you to deploy Next.js applications (see the docs here) using Firebase Hosting and Cloud Functions for Firebase.

In regard to how package-lock.json files are managed, the package-lock.json that is included with your source should be respected when dependencies are installed on Google Cloud infrastructure. Using Cloud Functions for Firebase alone should not generate a .firebase folder in your source directory. It's hard to diagnose exactly what's going on without more specifics about your situation, but I would definitely suggest trying out the Web Frameworks feature if you are trying to deploy a Next.js application.

[steebchen]

@blidd-google Thanks, yes, I am using the web frameworks feature with NextJS. It's like I said though, when I run firebase deploy with web frameworks (NextJS), it creates a new package.json in .firebase and then creates a new lockfile as well with new dependencies.

To be more specific, I am using this starter NextJS project https://github.com/gladly-team/next-firebase-auth/tree/v1.x/example. The application deploys fine to firebase hosting+functions, however I am running into an issue which I don't have locally or on Vercel (something doesn't work around the auth, but firebase itself works on the clienet, and firestore on the server (aka functions) also works fine). So my conclusion is that it has to be some not right (sub)module version due do this package-lock.json recreation. But even if it wasn't, I am still concerned about the fact that there are additional dependencies installed in your existing package.json and the lockfile seemingly not being respected.

Another example to make this clear may be simply that if you use yarn like in the example above, there is still a package-lock.json generated in the .firebase folder, so this means the original lockfile is just not respected.

[inlined]

Sorry for the delay. This is actually handled by a different team and I've notified them. For the future, github.com/firebase/firebase-tools is the repo monitored for web frameworks bugs.

[steebchen]

I can re-create the issue there if needed

[tmhrbr]

It should also respect package manager used in the project. Installing with npm is failing on peer dependencies where Yarn does not.