feat: use packageManager as a attempt to identify node package manager

[arthurfiorette]

When running nixpacks inside pnpm monorepos a lockfile will not be present at cwd, to avoid this problem it attempts to first read the package.json packageManager field before trying to read lockfiles until a match is found.

Ideally would be great if we could choose a package manager as a configurable option for nixpacks.toml but since I did not see any other providers using dedicated configurations for a provider I was not sure if that's something desired to have...

[arthurfiorette]

@coffee-cup I've fixed linting and improved documentation to state that now packageManager field is taking into account.

[arthurfiorette]

There's another problem when running with pnpm workspaces:

In latest's pnpm version, only one lockfile is present in the root of the project, meaning no packageManager neither pnpm-lockfile.yaml will be present near the project structure. To avoid giant refactors to take account a "root" folder being different from the project structure, we could use pnpm deploy instead of install and build recursively all dependencies.

pnpm deploy --filter=<npm package name> ./target
cd target
pnpm build --filter=<npm package name>...

Doing something like the above, deploy will install only the required dependencies into a subfolder build (with ... at the end) would build all local dependencies of the project before building itself, making working with monorepos just like normal packages. In the case of a single package, deploy and build would work just like if it was in a workspace.

This is also how pnpm itself recommend building docker images.

What do you think about this?

[arthurfiorette]

We could even improve installing times by firstly copying only pnpm-lock.yaml and running a fetch to load all dependencies before copying the whole project so dependencies gets cached in a layer that is resistant to changes in the codebase and even non-dep changes to package.json

[coffee-cup]

Thanks for the docs and lint fixes. I’m afk until Monday and will merge and release it then.

Great ideas for improving the pnpm provider too. Fetching deps in an another layer would certainly help deploy times. I’m a bit unsure why it is an issue if there is only a single lockfile at the root though. Does that not work with the current system?

[arthurfiorette]

If the lockfile is in the workspace's root and I build in a subfolder, pnpm inside docker will not be aware of the monorepo, nor local dependencies installed with workspace:* protocol or a local lockfile. Hence, it breaks when installing with --frozen-lockfile because there's no lockfile. But even removing frozen lockfile local dependencies (the most basic feature of workspaces) would also break.

[coffee-cup]

Ah I see. Yes in that case it is recommended to build from the root and build a specific package with --filter.

[arthurfiorette]

Hey @coffee-cup but in that case the build wouldn't invalidate its cache on any unrelated change across the entire workspace?