nx-firebase: `@nx/esbuild` Does not output pruned `package-lock.json`
When building a firebase function, @nx/esbuild will output a package.json in dist containing the functions dependencies due to generatePackageJson: true.
However, the @nx/esbuild plugin does not output a pruned package-lock.json file which other Nx plugins like @nx/webpack and @nx/node do.
Without a package-lock.json file in dist, when firebase deploys this function, it may run npm ci and generate dependencies that are different from the ones in the workspace root package-lock.json, and ultimately fail to deploy if there are incompatible peer deps.
This issue lies with Nx and requires a fix on their side.
About this issue
- Original URL
- State: closed
- Created 8 months ago
- Reactions: 1
- Comments: 15 (8 by maintainers)
It gets wierder - the migration tool for Nx 17.0.0 has an explicit migration to remove this build option from all targets! 🔥
https://github.com/nrwl/nx/blob/ac038e353c32b96655aa8c6145d6d0666361fe76/packages/js/src/migrations/update-17-0-0/remove-deprecated-build-options.ts#L27C37-L27C37
Thats great news. I’ve seen this option lurking around in various discussions, but it never seemed to be documented anywhere. At the time of writing its not mentioned on the
@nx/esbuilddocs: https://nx.dev/nx-api/esbuild/executors/esbuildIt’s not an option listed in the esbuild plugin schema either, so I dont really know why or how this works, but yeah, let’s take the win 😅
It’s worth noting that because it’s Nx that is populating this list, it will likely be every dependency that Nx believes your code directly or indirectly accesses - so any imports from libraries you have will be likely included and causing this bloat. At least it is correct though, even if overkill.
Ideally it would be esbuild that writes this
package.jsonbecause the dependency list after tree shaking as you say should be typically much smaller, but that would need looking into. I remember looking into this a while ago and used an esbuild plugin to write it, but then Nx just overwrites it after compilation is complete. 😕I doubt this has much impact in practice, probably just means that functions will be using up a bit more firebase storage budget since the container for your function will have a larger
node_modulesthan necessary.Not at all, this is totally on topic with the OP
@simondotm This worked!
It wasn’t there before if you are wondering.
Now there’s a
package.jsonand a (seemingly matching)package-lock.jsoninbuild/. The dependency list is a bit longer than necessary. I think with perfect tree-shaking it could have figured out that even though I imported a shared library, the only type I’ve imported doesn’t need any external code and is just one line.But hey, it works! Thank’s a lot for the help. I’m sorry if I unintentionally hijacked this issue with an unrelated question.
Yes, it’s generating both files, although there are no dependencies in either.
If I add dependencies to the template, they’re also present in the dist folder.