turbo
turbo copied to clipboard
Ignore pnpm-lock change in package content hashing computing.
Describe the feature you'd like to request
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?
Describe the solution you'd like
add blacklist config for package tasks, like this:
{
"inputIgnore": ["${workspaceFolder}/pnpm-lock.json"],
}
Describe alternatives you've considered
I see no other solutions, but I think the blacklist for input files are really important to provide a more granular build cache. If we don't have this feature, for pnpm repo, at least, the caches are almost unusable because so many factors may change the pnpm-lock file. As far as I know, for those "apps", which we need to bundle the dependencies into a big chunk (like what webpack always do), you need to ensure that once any dependencies change, you will need to rebuild the app, but for libraries, they only need to be transpiled from typescript into javascript, so nothing except the change of source files will change the output. For build of library, we need to give users an option to ignore unnecessary hash factors.
I'm facing the same problem, we are working on a monorepo based on pnpm
, every time when we add dependencies to one application, all the projects cache gets outdated.
It's quite frustrating when having big stable projects and actively developing projects at the same time in the monorepo because for actively developing projects, it's quite common to add/remove dependencies. When the cache gets outdated because of this, all other projects need to get rebuilt and re-test.
We're using fixed version dependencies, I think it should be safe to ignore the changes of pnpm-lock.yaml
, just relying on the project's package.json
should be good enough if I'm not mistaken.
This is a duplicate of #1304
The global lockfile is always part of the global hash. Seems like the feature request is to turn that off somehow. I'm not sure if that would result in more unexpected pain, but we'll take it as a feature request
As mentioned this is a duplicate of #1304 and we now have lockfile parsing that allow us to detect if a dependency of a package changed instead of if any part of the lockfile changed.