Is It Possible To Ignore pnpm-lock.json In Package Hit Hashing Algorithm?

[niudai]

I have a big pnpm monorepo, with tens of packages which I need to transpile from .ts to .js before developing (simply run prepare:dev script recursively before develop).

What I expect is only when the source files change, I need to rebuild these libraries, because the ./dist folder of these libaries are simply the output .js from .ts in src folder, it should not depend on the global pnpm-lock, or even the resolved version of packages's dependencies.

Everytime I change the pnpm-lock file a little bit, even add a blank line, all packages build caches are missed and need to be rebuilt locally.

For our team, since every commit to master branch triggers packages publishing and version bumping, the pnpm-lock file changes very frequently, which cause the build caches are always missed.

Am I missing something? Or Is This A Feature Being Developed?

[dobesv]

I'm the documentation it says that smart lock file processing only works for yarn. Perhaps you could look at how this is implemented for yarn and submit a PR to implement it for pnpm.

Or maybe just a PR to allow ignoring lock files completely. However, beware that if you ignore the lock file then you might not consistently pick up on errors caused by updates to dependencies. I'm not sure how package JSON is being processed here, whether a change to dependencies in the package will cause a rebuild.

[anthonyshew]

What you've described is how Turborepo is working for me with pnpm today! I believe this should be implemented with all package managers today. If you're seeing that this isn't working, please report in an issue with a reproduction!