yarn add with local path to tarball installs stale dependency contents

[vith]

Do you want to request a feature or report a bug?

bug

What is the current behavior? yarn add <path to tarball> results in stale contents from a previous unpacking in node_modules

If the current behavior is a bug, please provide the steps to reproduce.

$ docker run -it node:11.4.0 bash

paste input:

cd && mkdir app dep

# create original dep tarball
cd ~/dep && yarn init -y && echo '*** OLD ***' > index.js && yarn pack

# install it
cd ~/app && yarn init -y && yarn add ~/dep/dep-v1.0.0.tgz

# see what it contains
cat node_modules/dep/index.js 

# make new dep tarball
cd ~/dep && echo '*** NEW ***' > index.js && rm dep-v1.0.0.tgz && yarn pack

# try to install it but get old contents
cd ~/app && yarn add ~/dep/dep-v1.0.0.tgz && cat node_modules/dep/index.js

# "did you try turning it off and on again?"
cd ~/app && yarn add ~/dep/dep-v1.0.0.tgz && cat node_modules/dep/index.js

output:

root@a94fc136c282:/# cd && mkdir app dep
root@a94fc136c282:~# 
root@a94fc136c282:~# # create original dep tarball
root@a94fc136c282:~# cd ~/dep && yarn init -y && echo '*** OLD ***' > index.js && yarn pack
yarn init v1.12.3
warning The yes flag has been set. This will automatically answer yes to all questions, which may have security implications.
success Saved package.json
Done in 0.03s.
yarn pack v1.12.3
success Wrote tarball to "/root/dep/dep-v1.0.0.tgz".
Done in 0.04s.
root@a94fc136c282:~/dep# 
root@a94fc136c282:~/dep# # install it
root@a94fc136c282:~/dep# cd ~/app && yarn init -y && yarn add ~/dep/dep-v1.0.0.tgz
yarn init v1.12.3
warning The yes flag has been set. This will automatically answer yes to all questions, which may have security implications.
success Saved package.json
Done in 0.03s.
yarn add v1.12.3
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...

success Saved lockfile.
success Saved 1 new dependency.
info Direct dependencies
└─ [email protected]
info All dependencies
└─ [email protected]
Done in 0.14s.
root@a94fc136c282:~/app# 
root@a94fc136c282:~/app# # see what it contains
root@a94fc136c282:~/app# cat node_modules/dep/index.js 
*** OLD ***
root@a94fc136c282:~/app# 
root@a94fc136c282:~/app# # make new dep tarball
root@a94fc136c282:~/app# cd ~/dep && echo '*** NEW ***' > index.js && rm dep-v1.0.0.tgz && yarn pack
yarn pack v1.12.3
success Wrote tarball to "/root/dep/dep-v1.0.0.tgz".
Done in 0.05s.
root@a94fc136c282:~/dep# 
root@a94fc136c282:~/dep# # try to install it but get old contents
root@a94fc136c282:~/dep# cd ~/app && yarn add ~/dep/dep-v1.0.0.tgz && cat node_modules/dep/index.js
yarn add v1.12.3
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
info Direct dependencies
└─ [email protected]
info All dependencies
└─ [email protected]
Done in 0.11s.
*** OLD ***
root@a94fc136c282:~/app# 
root@a94fc136c282:~/app# # "did you try turning it off and on again?"
root@a94fc136c282:~/app# cd ~/app && yarn add ~/dep/dep-v1.0.0.tgz && cat node_modules/dep/index.js
yarn add v1.12.3
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved 0 new dependencies.
Done in 0.08s.
*** NEW ***

What is the expected behavior? new dependency contents on first try

Please mention your node.js, yarn and operating system version.

root@261dd9a2ad65:~/app# yarn -v
1.12.3
root@261dd9a2ad65:~/app# node -v
v11.4.0
root@261dd9a2ad65:~/app# cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[vith]

Note: yarn cache clean dep also doesn't help: https://github.com/yarnpkg/yarn/issues/5357

If you switch between absolute and relative paths to the tarball, that does work on the first try.

So I guess the cache is being used first, then updated, and it's keyed by the string passed in and not the resolved full path.

[otakustay]

In my case call a yarn install after yarn add <local path> can build a correct node_modules most times

[marcoms]

npm install <path>.tar.gz seems to work, if anyone wants a quick and dirty solution.

[eppsilon]

It looks like the cache contains a copy of the tarball in the .tmp directory. Not sure if it is safe to do so, but deleting .tmp fixed this issue for me.

[ZelphirKaltstahl]

Still facing this problem from time to time, especially with third party projects, that rely on using Yarn to install plugins. One example: JupyterLab, which has its own Yarn.

[bensewell]

I just hit the identical issue

[flex-mookeun]

For those facing this issue, a workaround could be cleaning your global yarn cache (typically ~/.yarn/berry/cache) or removing the package with issue from there so that yarn could install the package from the given tgz file.

[pencilcheck]

Is this resolved? or is it still going to install stale content?

[ZelphirKaltstahl]

Is this resolved? or is it still going to install stale content?

It seems there is no reason to assume, that this will ever be fixed or that anyone developing yarn is interested. I recommend to switch to another dependency manager, if possible.

[pencilcheck]

Is this resolved? or is it still going to install stale content?

It seems there is no reason to assume, that this will ever be fixed or that anyone developing yarn is interested. I recommend to switch to another dependency manager, if possible.

well, some projects like expo/react native forces me to use yarn in monorepo so i'm sort of stuck :\