-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Yarn will not upgrade ember-source package from 3.1.0 to 3.1.1 #5723
Comments
Wow, how did this break? 😞 confirmed on 1.6.0.
you could also do |
Debugging notes: The file
The size isn't surprising, but the modified time is. yarn looks at those 2 values to compare a file in the cache to a file already in node_modules to see if it needs to be recopied. In the verbose log we see:
so it is leaving the previous (3.1.0) file in place. I think this problem is isolated to these specific versions due to them being last modified in the same second. I checked other version's package.json modified times:
Also those duplicate timestamps are on Removing the [high-priority] tag since this seems isolated to changing between just these 2 versions that seem to have incorrect timsestamps. |
Seeing another package not honoring the
Looks like the same issue... |
Same with |
Just ran into another: This really does seem to be a rather problematic bug... We're running into it w/ different packages almost everyday... Should we open a cross-referenced bug ticket over at https://github.com/npm/npm/issues to see if that team can help? |
Nm.. just did ☝️ |
FYI... just tried this again w/ |
Just FYI, the timestamps being in 1985 is intentional: npm/npm#20615 (comment) |
That thread is now locked. Anyone here in Yarn world have any ideas? |
I am running into this issue, also. Does the yarn team have a plan to cope with the npm team's decision to set a common timestamp for all files in all published packages? |
We just started running into this in our project as well. Some files for some packages now show the weird 1985 timestamp and for these packages, |
Man.. almost 2 months, and still nothing? You'd think this would be a higher priority due to the possibility of packages not receiving security updates and such.... |
npm 6 locks mtime of all files in the published tarball to be October 26th 1985, which means mtime is no longer changed when a package is published with an npm version above 6. See: https://npm.community/t/tarball-content-timestamps-locked-to-1985/149 Fixes: yarnpkg#5723
npm 6 locks mtime of all files in the published tarball to be October 26th 1985, which means mtime is no longer changed when a package is published with an npm version above 6. See: https://npm.community/t/tarball-content-timestamps-locked-to-1985/149 Fixes: yarnpkg#5723
…#6010) npm 6 locks mtime of all files in the published tarball to be October 26th 1985, which means mtime is no longer changed when a package is published with an npm version above 6. See: https://npm.community/t/tarball-content-timestamps-locked-to-1985/149 Fixes: #5723
I seem to have just gotten something similar for Ember Data:
|
* Revert "fix(util/fs): use file content instead of mtime to determine equality (#6010)" This reverts commit c53d039. * Bumps the cache version * Forces the mtime to be based on the time the archives got fetched * Fixes subseconds time assignment (nodejs/node#22070) * Adds regression tests for #5723 * Fixes tests * Fixes test on architectures that don't support subsecond precision
* Revert "fix(util/fs): use file content instead of mtime to determine equality (#6010)" This reverts commit c53d039. * Bumps the cache version * Forces the mtime to be based on the time the archives got fetched * Fixes subseconds time assignment (nodejs/node#22070) * Adds regression tests for #5723 * Fixes tests * Fixes test on architectures that don't support subsecond precision
* Improve CircleCI scripts * Upgrade to [CircleCI 2.1 configuration](https://github.com/CircleCI-Public/config-preview-sdk) * Use reusable commands and jobs with parameters, instead of aliases * Upgrade Yarn before installing dependencies, if needed: fixes issue #1648, which is caused by yarnpkg/yarn#5723 * Skip Flow, Jest, and coverage report upload if only website and documentation are changed: fixes #1655 * Add Codecov flags: https://docs.codecov.io/docs/flags * Set CIRCLE_PREVIOUS_BUILD_NUM empty before running greenkeeper-lockfile: it detects the correct build by checking it's the first job of the first workflow. As we run jobs parallel, the correct build may not be the first job. * Remove CircleCI build artifacts for now: it's highly unlikely we'll use them * Add comments for #1590 workaround * Update name * Fix command operator precedence * Remove workflow version
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Changing version of
ember-source
from3.1.0
to3.1.1
inpackage.json
deps and runningyarn install
updates lock file to3.1.1
, but actual package innode_modules
remains3.1.0
If the current behavior is a bug, please provide the steps to reproduce.
yarn init
package.json
w/"ember-source": "3.1.0"
under depsyarn install
cat node_modules/ember-source/package.json
3.1.0
(expected)ember-source
to3.1.1
inpackage.json
yarn install
install
(notice, lock file updated, but not packages were installed/upgraded)yarn.lock
forember-source
, version is correctly recorded as3.1.1
cat node_modules/ember-source/package.json
3.1.0
🐛 🐞What is the expected behavior?
ember-source
is now3.1.1
Please mention your node.js, yarn and operating system version.
OSX 10.13.4
Note: Only workaround we could find was to nuke
node_modules
and reinstall depsThe text was updated successfully, but these errors were encountered: