turbo icon indicating copy to clipboard operation
turbo copied to clipboard

Ignore pnpm-lock change in package content hashing computing.

Open niudai opened this issue 1 year ago • 2 comments

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.

niudai avatar Jul 11 '22 02:07 niudai

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.

ruanyl avatar Aug 19 '22 07:08 ruanyl

This is a duplicate of #1304

Dwlad90 avatar Sep 21 '22 13:09 Dwlad90

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

mehulkar avatar Oct 20 '23 18:10 mehulkar

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.

chris-olszewski avatar Dec 04 '23 18:12 chris-olszewski