Repository navigation
yarn probably shouldn't cache packages resolved with a file path #2165
Description
Do you want to request a feature or report a bug?
I guess a bug.
What is the current behavior?
If the current behavior is a bug, please provide the steps to reproduce.
Say you have the following project structure:
component-foo/
└── package.json
└── index.js
yarn-test/
└── package.json
With the following files:
component-foo/package.json:
{
"name": "component-foo",
"version": "1.0.0",
"private": true,
"main": "index.js"
}
component-foo/index.js:
console.log('foo');
yarn-test/package.json:
{
"name": "yarn-test",
"version": "1.0.0",
"private": true,
"dependencies": {
"component-foo": "file:../component-foo"
}
}
Now you run $ yarn install inside yarn-test/ and yarn-test/node_modules/component-foo/index.js is:
console.log('foo');
Now remove yarn-test/node_modules/ and yarn-test/yarn.lock and change component-foo/index.js to this:
console.log('bar');
Now you run $ yarn install inside yarn-test/ again and yarn-test/node_modules/component-foo/index.js will be:
console.log('foo');
It uses the cached version of component-foo, but component-foo/index.js has changed.
What is the expected behavior?
I'd expect that yarn-test/node_modules/component-foo/index.js should be this at the end:
console.log('bar');
Maybe packages installed with local paths like file:../ shouldn't be cached at all, if we can't figure out, if they have changed.
(FYI: It looks like npm doesn't cache them.)
Please mention your node.js, yarn and operating system version.
$ node -v
v6.9.1
$ yarn -V
0.18.0
macOS 10.12.1
Activity
hantuzun commentedon Dec 13, 2016
This fooled me as well. There must be a way to get around this without clearing all the cache.
I think there could the three ways to make yarn usable for this case:
file://<path>@<cache_timestamp>yarn cache rm <package>andyarn cache add <package>. For all dependencies.I'd like to see the second suggestion to be implemented. Unless, the third option could be useful for other cases as well. For instance,
yarn cache add <package>can be used to refresh the cache for already cached dependencies in case something could go wrong while downloading a dependency.satya164 commentedon Dec 25, 2016
@hantuzun why cache local dependencies at all? they are local anyways, so it will be fast regardless cached or not.
hantuzun commentedon Dec 26, 2016
@satya164 you're right. Although, I'm more inclined to the third approach would help if a dependency from network is modified intentionally.
satya164 commentedon Dec 26, 2016
Something like
yarn cache ignore <package>will be useful. But I think they don't have to be mutually exclusive. Ignoring a package is useful, but it requires manual work. File dependencies could be made to work without any additional effort if they were ignored by default.donaldpipowitch commentedon Jan 4, 2017
Can someone explain me the internal logic?
My understanding:
When a dependency with
file:is encountered thefile-resolver.jskicks in. It says the dependency should be copied and is not hashed. Doesn't no hash mean it should not be cached already...? But thecopy-fetcher.jsseems to set the hash to an empty string instead of keepingnull... Is this problem?donaldpipowitch commentedon Jan 10, 2017
@bestander or @kittens Maybe you could explain this a little bit more...? Would love to get a little help to create a PR ♥
bestander commentedon Jan 10, 2017
Hash means the md5 hash that is used for tarball-fetcher, for example.
This hash is then added to yarn.lock file for future verifications and also appended to folder name when saving the unzipped folder in cache.
You are digging in the right direction, thanks for looking into this, a PR is very much welcome.
You can probably start with a PR that adds a broken unit tests
donaldpipowitch commentedon Jan 10, 2017
Okay, thank you for your response. Should I ping you as a reviewer in the PR or should I ping someone else (or no one)...?
bestander commentedon Jan 10, 2017
Yeah, ping me
added failing unit test for yarnpkg#2165
don't cache dependencies installed with file: protocol - fixes #2165 (#…
satya164 commentedon Jan 26, 2017
@bestander probably this issue shouldn't be closed since it's not fixed yet?
donaldpipowitch commentedon Jan 26, 2017
Yes, it should be re-opened. It was closed because I wrote " fixes #2165" in the title of my PR. In the beginning I thought it would be an ongoing PR, but to fix this bug we want two PRs: the first one added a unit test (the assertion which would fail is not really active, so CI doesn't blow up) and the second one will actually fix it.
bestander commentedon Jan 26, 2017
Sorry, github closes issues when PR is merged
62 remaining items
ojboj commentedon Jan 22, 2020
@souporserious That is exactly what I needed/wanted, thank you so much!
bobber205 commentedon Mar 11, 2020
Insane this is still an issue after so many years.
wKich commentedon Mar 13, 2020
Is it fixed in yarn@2.x?
souporserious commentedon Mar 13, 2020
@wKich I believe so! I haven't personally tested it, but it looks like they solve local development through the new portal protocol.
garyo commentedon May 26, 2020
I still get "unpack in same destination" error using the
link:protocol, and it's referencing my cache dir, so it seems to me yarn is still cachinglink:dependencies. I'm referencing 2 copies of the same local package, copied into the.deps/folder of each app that uses it --front-endandrendererin the error below. (Can't link to the original for unrelated reasons)thejohnfreeman commentedon Jun 30, 2021
This issue is not fixed by the
link:andportal:protocols for those of us like @ojboj and me who install packages from a tarball instead of a directory, e.g.file:path/to/dependency.tgz. One annoying workaround is to use a throwaway cache directory likeyarn install --cache-folder $(mktemp -d). My preferred workaround is to just bust the cache for every offline dependency:rm -rf $(yarn cache dir)/.tmp. Thanks to @wKich for the detective work.geoidesic commentedon Aug 10, 2022
Why is this closed?
I still get this issue in Yarn 1.22.19... Yarn caches local packages, which is not helpful for development.
justsaul commentedon Sep 15, 2022
Believe it or not, it's still an issue with yarn berry (3+). I wish there were better alternatives to deal with devDeps.
hoegge commentedon Sep 16, 2022
It is actually 4+ years #6037
sickdyd commentedon Nov 20, 2022
When developing a package with React 18 I had various issues using
yarn link, so I just rely on building a local package and installing in my React app, this issue is pretty annoying... there should be some way to forcefully reinstalling the single local package ignoring the cache instead of usingyarn cache clean.www: yarn: workaround local package caching
bysiber commentedon Mar 2, 2026
Remove usage of yarn from critical path.