Skip to content
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

Closed
RavenHursT opened this issue Apr 24, 2018 · 13 comments
Closed

Yarn will not upgrade ember-source package from 3.1.0 to 3.1.1 #5723

RavenHursT opened this issue Apr 24, 2018 · 13 comments
Assignees
Labels

Comments

@RavenHursT
Copy link

RavenHursT commented Apr 24, 2018

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

Bug

What is the current behavior?
Changing version of ember-source from 3.1.0 to 3.1.1 in package.json deps and running yarn install updates lock file to 3.1.1, but actual package in node_modules remains 3.1.0

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

  • create a new yarn project w/ yarn init
  • create package.json w/ "ember-source": "3.1.0" under deps
  • run yarn install
  • cat node_modules/ember-source/package.json
  • version remains 3.1.0 (expected)
  • manually change ember-source to 3.1.1 in package.json
  • yarn install
  • Output from install (notice, lock file updated, but not packages were installed/upgraded)
yarn install v1.6.0
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
✨  Done in 0.55s.
➜  derp rg ember-source yarn.lock
119:[email protected]:
121:  resolved "https://registry.yarnpkg.com/ember-source/-/ember-source-3.1.1.tgz#9cf95e8a6d7568d60b8eda2aeda17ac8944e654b"
  • Search yarn.lock for ember-source, version is correctly recorded as 3.1.1
  • cat node_modules/ember-source/package.json
  • Actual module version remains 3.1.0 🐛 🐞

What is the expected behavior?
ember-source is now 3.1.1

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

$ node --version
v9.11.1
$ yarn --version
1.5.1

OSX 10.13.4

Note: Only workaround we could find was to nuke node_modules and reinstall deps

@ghost ghost assigned rally25rs Apr 24, 2018
@ghost ghost added the triaged label Apr 24, 2018
@rally25rs
Copy link
Contributor

Wow, how did this break? 😞 confirmed on 1.6.0.

Only workaround we could find was to nuke node_modules and reinstall deps

you could also do yarn install --force and it will force re-copy all the files. I'll dig in and see if I can figure out what's going on...

@rally25rs
Copy link
Contributor

rally25rs commented Apr 25, 2018

Debugging notes:

The file size and mtime are exactly the same between versions 3.1.0 and 3.1.1

~/Projects/yarn-test 🐒   stat -f "%z %m" -t "%s" /Users/jvalore/Library/Caches/Yarn/v1/npm-ember-source-3.1.0-21902747801c747b615f60168712968db3b433fc/package.json
4603 499162500

~/Projects/yarn-test 🐒   stat -f "%z %m" -t "%s" /Users/jvalore/Library/Caches/Yarn/v1/npm-ember-source-3.1.1-9cf95e8a6d7568d60b8eda2aeda17ac8944e654b/package.json
4603 499162500

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:

verbose 0.689 Skipping copying of file "/Users/jvalore/Library/Caches/Yarn/v1/npm-ember-source-3.1.1-9cf95e8a6d7568d60b8eda2aeda17ac8944e654b/package.json" as the file at "/Users/jvalore/Projects/yarn-test/node_modules/ember-source/package.json" is the same size (4603) and mtime (499162500000).

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:

3.0.0        = 1518583481
3.1.0        = 499162500
3.1.0-beta.1 = 1518621324
3.1.0-beta.2 = 1519085839
3.1.1        = 499162500

Also those duplicate timestamps are on 10/26/1985 which is clearly not the correct timestamp. I know there were a couple npm bugs that were corrupting timestamps, but not sure if this is related.

Removing the [high-priority] tag since this seems isolated to changing between just these 2 versions that seem to have incorrect timsestamps.

@RavenHursT
Copy link
Author

Seeing another package not honoring the yarn.lock version as well now:

Missing yarn packages: 
Package: c3
  * Specified: 0.5.4
  * Installed: 0.5.3

Run `yarn` to install missing dependencies.

Looks like the same issue...

@le0nik
Copy link

le0nik commented May 11, 2018

Same with colors. Always installs 1.2.3, even though the version is 1.2.4 in package.json and yarn.lock.

@RavenHursT
Copy link
Author

Just ran into another: esm package is marked as 3.0.33 but installs 3.0.26

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?

@RavenHursT
Copy link
Author

Nm.. just did ☝️

@RavenHursT
Copy link
Author

FYI... just tried this again w/ [email protected] and got the same result: npm/npm#20615 (comment)

@legodude17
Copy link

Just FYI, the timestamps being in 1985 is intentional: npm/npm#20615 (comment)

@RavenHursT
Copy link
Author

That thread is now locked. Anyone here in Yarn world have any ideas?

@amarsan
Copy link

amarsan commented Jun 8, 2018

I am running into this issue, also. yarn install --force does not help because it does not cause all files in yarn's cache to be copied to the local node_modules directory. @RavenHursT 's workaround, deleting the node_modules directory, does work for me, but that's not ideal.

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?

@kaiyoma
Copy link

kaiyoma commented Jun 18, 2018

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, yarn does not correctly install/update files on disk. We also now have to resort to blowing away node_modules for each build, but this is massively inefficient. I'd also like to see yarn fix this quickly.

@RavenHursT
Copy link
Author

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....

rufman added a commit to rufman/yarn that referenced this issue Jun 19, 2018
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
rufman added a commit to rufman/yarn that referenced this issue Jun 20, 2018
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
arcanis pushed a commit that referenced this issue Jun 21, 2018
…#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
@lougreenwood
Copy link

I seem to have just gotten something similar for Ember Data:

Missing yarn packages: 
Package: ember-data
  * Specified: ^3.3.0
  * Installed: 3.2.0

arcanis pushed a commit to arcanis/yarn that referenced this issue Aug 1, 2018
arcanis added a commit that referenced this issue Aug 3, 2018
* 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
arcanis added a commit that referenced this issue Aug 3, 2018
* 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
kevinbarabash pushed a commit to KaTeX/KaTeX that referenced this issue Sep 3, 2018
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants