Open borekb opened 3 years ago
We had a similar problem.
The checksum calculation differs between Linux CI/CD and Windows Developer System.
Our Solution: We moved the <pkg>@file:<path>
into a seperate private NPM Registry. Now the checksum is consistent.
We have run into exactly same issue. After upgrading from classic Yarn (v1) to latest one (3.2.0), our CI is failing with one of the file:
dependencies.
In my opinion, the checksum
should not be calculated based on whole directory but based on files
configuration from package.json
. What is the point of saying which files should be included in final lib if checksum is incorrectly calculated.
We are also facing the very same issue (when upgrading from v1.x to v3.x), is there any resolution for it yet ?
worse decision in my life to upgrade from yarn1 in corepack to yarn3 this broke my CI
Seems like the only workaround is using a portal resolution link e.g. yarn link -r --private ../../packages/lib
. This prevents creation of the checksum hash altogether...
"resolutions": {
"lib": "portal:../../packages/lib"
}
The portal:
workaround does not work with lerna which only supports file:
and workspace:
. I cannot migrate to workspaces easily yet. Is there another workaround? For example, a way to disable hash calculation in metapackage setting?
@krassowski Yeah it will be a issue for monorepo tools that don't support portal:
. From my case, it works with my setup using turbo.
My use case is bundling some relative workspace dependencies via:
enableGlobalCache: false
nodeLinker: pnp
Works great but I had a big data
folder which was meant to be ignored that got bundled in and tripped me up for a bit, leading me to this long lasting bug report.
Describe the user story
I have an
app
that depends onlib
via thefile:
protocol:In
app/yarn.lock
, I'll get something like this after runningyarn
:The problem is that the hash and a checksum in the lockfile are calculated from the
a
directory as a whole, including files like.DS_Store
, node_modules or any gitignored files. Changing any of those will produce a new "folderHash" and a checksum:In practice, we see a changed
yarn.lock
all the time and need to revert it manually. We wish these changes in gitignored / npmignored files didn't change the lockfile.Also, I think that copying node_modules from the referenced package might lead to "incorrect installs" –
lib
might havenode_modules
installed or not, which might affect which versions of packagesapp
resolves. (In general, I could have also messed withlib/node_modules
manually and it feels wrong that this should affectapp
.)Describe the solution you'd like
I think that the hash should use the same helper functions as
yarn pack
(probably functions likegetPackList
inplugin-pack/sources/packUtils.ts
).Describe the drawbacks of your solution
It's a change in behavior and maybe someone wants their dependencies to be re-fetched into the cache even if files like
.DS_Store
or something insidenode_modules
changes? I'm not sure.Describe alternatives you've considered
Currently, in README, we instruct developers to revert
yarn.lock
changes that are caused by their local gitignored files.(Note: this was initially discussed in Discord, see this message and below.)
Search terms: file protocol, gitignored files, gitignore, npmignored files, npmignore,
yarn pack