yarn add with local path to tarball installs stale dependency contents
vith opened this issue · 10 comments
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 bashpaste 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.jsoutput:
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
└─ dep@1.0.0
info All dependencies
└─ dep@1.0.0
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
└─ dep@1.0.0
info All dependencies
└─ dep@1.0.0
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/"Note: yarn cache clean dep also doesn't help: #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.
In my case call a yarn install after yarn add <local path> can build a correct node_modules most times
npm install <path>.tar.gz seems to work, if anyone wants a quick and dirty solution.
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.
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.
I just hit the identical issue
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.
Is this resolved? or is it still going to install stale content?
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.
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 :\