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

Disables by default the migrations #6465

Merged
merged 5 commits into from Oct 2, 2018

Conversation

arcanis
Copy link
Member

@arcanis arcanis commented Oct 2, 2018

Summary

While not breaking technically speaking, the automatic migration is causing unexpected behaviors to our users. Such a behavior should only happen when bumping the major version.

To prevent that, the unsafe-disable-integrity-migration settings will default to true for the duration of the 1.X branch. It will default to false again starting with the 2.0.

In order to migrate your project now, just add the following line into your project-local yarnrc:

unsafe-disable-integrity-migration "false"

Note that this only affect the lockfile entries already present in your lockfile. Yarn will continue to create the new entries using the integrity field. My guess is that by the time the 2.0 lands, enough projects will have been migrated to use the integrity field that this will be a painless transition.

Test plan

CI

@arcanis arcanis requested a review from imsnif October 2, 2018 10:50
Copy link
Member

@imsnif imsnif left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about adding a warning message that would explain this to the user (or link to a help page with more details)? unsafe-disable-integrity-migration which defaults to true is a bit of a handful (double negative + unsafe). (EDIT: double negative if it's explicitly disabled, that is :) )

Also about migrating: I realize this is inevitable, but we'll still have mutations between versions (if I add a package with integrity, it will be stripped when someone runs yarn with a previous version).

src/config.js Outdated
@@ -408,6 +408,8 @@ export default class Config {
}
}

const toBool = value => value !== 'false' && value !== 'no' && value !== '0';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The boolifyWithDefault function in src/util.js might be appropriate to use here instead of introducing a new function.

@arcanis
Copy link
Member Author

arcanis commented Oct 2, 2018

What do you think about adding a warning message that would explain this to the user (or link to a help page with more details)?

Not sure - should we print the warning every time? It would be very verbose (especially if it includes a link). It sounds like the kind of thing that users will just ignore since "it works".

@Gudahtt
Copy link
Contributor

Gudahtt commented Oct 2, 2018

I would suggest that the option could be renamed to avoid the double-negative, but then the unsafe- prefix ceases to make sense. We don't want to imply that migrations are unsafe.

I don't think printing a warning each time is warranted - there is nothing actionable here for the user to do.

@arcanis
Copy link
Member Author

arcanis commented Oct 2, 2018

Yep, the double negation was because I preferred to make it explicit that we recommend this option not to be turned on (a bit like DO_NOT_USE_OR_YOU_WILL_BE_FIRED).

@buildsize
Copy link

buildsize bot commented Oct 2, 2018

File name Previous Size New Size Change
yarn-[version].noarch.rpm 1.09 MB 1.09 MB 40 bytes (0%)
yarn-[version].js 4.26 MB 4.26 MB 247 bytes (0%)
yarn-legacy-[version].js 4.44 MB 4.44 MB 243 bytes (0%)
yarn-v[version].tar.gz 1.1 MB 1.1 MB 1.69 KB (0%)
yarn_[version]all.deb 803.62 KB 803.55 KB -76 bytes (0%)

@imsnif
Copy link
Member

imsnif commented Oct 2, 2018

A message each time might indeed be excessive. Maybe some documentation somewhere like here then? https://yarnpkg.com/lang/en/docs/yarnrc/

@arcanis
Copy link
Member Author

arcanis commented Oct 2, 2018

@imsnif Do you have an idea why the bailout tests are failing?

@imsnif
Copy link
Member

imsnif commented Oct 2, 2018

@arcanis - my guess would be something to do with https://github.com/yarnpkg/yarn/blob/master/src/cli/commands/install.js#L465
But I'll have to take a closer look. Can do later tonight if it can wait.

@arcanis
Copy link
Member Author

arcanis commented Oct 2, 2018

Thanks, that was it, problem fixed!

@rjmunro
Copy link
Contributor

rjmunro commented Oct 8, 2018

There are 2 kinds of project out there. Ones with 1.9 type lock files (no integrity), and ones with 1.10 lock files (with integrity). Yarn should work with both, and preserve them it that state until the project decides to upgrade them to the new format. A warning should be given to remind people to do that.

Making a third, hybrid format lockfile that has only some integrity entries is no use to 1.10 users because it doesn't really check the integrity, and even worse for 1.9 users because they will strip the integrity lines and have to commit the yarn.lock file each time a 1.10 user adds something.

@arcanis
Copy link
Member Author

arcanis commented Oct 8, 2018

Making a third, hybrid format lockfile that has only some integrity entries is no use to 1.10 users because it doesn't really check the integrity

Yarn will check the integrity. It just will keep using the sha1 for old ones. The main reason we've disabled the migration by default is that the lockfile should not change when you run yarn install on an up-to-date project, except between major releases.

ikatyang added a commit to prettier/prettier that referenced this pull request Oct 27, 2018
Yarn v1.10 adds `integrity`s but v1.9 removes them.
Add this option to prevent them from adding unnecessary diffs all the time.
This is the default value for Yarn v1.12+ (ref: yarnpkg/yarn#6465).
@borekb
Copy link

borekb commented Nov 2, 2018

A bit OT but since we're fighting this integrity field in our team where not everyone is on the same Yarn version (I know...), is there a way to pass unsafe-disable-integrity-migration from the command-line?

@rjmunro
Copy link
Contributor

rjmunro commented Nov 2, 2018

@arcanis I'm seeing random integrity entires being added, depending on who / where yarn is being run, then being removed again when someone on an old version runs it. These all go into version control. It's a total mess. There should only ever be all or no entries. Which state a particular lock file is in should be left alone unless the user changes it (e.g. by running something like a special command, maybe yarn upgrade-lockfile).

At the very least, weather or not to include the entries should be something that happens to a project, not something done by a user.

@arcanis
Copy link
Member Author

arcanis commented Nov 2, 2018

@borekb @rjmunro this doesn't entirely answer your question, but are you aware that you can very easily force all of your team to use the exact version of Yarn you want them to use?

Just create a .yarnrc in your repositories, add yarn-path "./scripts/yarn-1.12.1.js" inside, add the single-file release to the right place, commit all this, and voilà. As long as your developers have Yarn 1.0 globally installed (which is more than one year old), Yarn will transparently use the version you've selected over the global one 🙂

We use this pattern at work and it's extremely handy to force everyone to upgrade at once, or to rollback everyone if we find a regression.

@borekb
Copy link

borekb commented Nov 5, 2018

@arcanis That is a clever trick, thank you!

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Nov 22, 2018
Changelog tracks back up to 1.12.0 only.

## 1.12.3

**Important:** This release contains a cache bump. It will cause the very first install following the upgrade to take slightly more time, especially if you don't use the [Offline Mirror](https://yarnpkg.com/blog/2016/11/24/offline-mirror/) feature. After that everything will be back to normal.

- Fixes an issue with `yarn audit` when using workspaces

  [6625](yarnpkg/yarn#6639) - [**Jeff Valore**](https://twitter.com/codingwithspike)

- Uses `NODE_OPTIONS` to instruct Node to load the PnP hook, instead of raw CLI arguments

  **Caveat:** This change might cause issues for PnP users having a space inside their cwd (cf [nodejs/node24065](nodejs/node#24065))

  [6479](yarnpkg/yarn#6629) - [**Maël Nison**](https://twitter.com/arcanis)

- Fixes Gulp when used with Plug'n'Play

  [6623](yarnpkg/yarn#6623) - [**Maël Nison**](https://twitter.com/arcanis)

- Fixes an issue with `yarn audit` when the root package was missing a name

  [6611](yarnpkg/yarn#6611) - [**Jack Zhao**](https://github.com/bugzpodder)

- Fixes an issue with `yarn audit` when a package was depending on an empty range

  [6611](yarnpkg/yarn#6611) - [**Jack Zhao**](https://github.com/bugzpodder)

- Fixes an issue with how symlinks are setup into the cache on Windows

  [6621](yarnpkg/yarn#6621) - [**Yoad Snapir**](https://github.com/yoadsn)

- Upgrades `inquirer`, fixing `upgrade-interactive` for users using both Node 10 and Windows

  [6635](yarnpkg/yarn#6635) - [**Philipp Feigl**](https://github.com/pfeigl)

- Exposes the path to the PnP file using `require.resolve('pnpapi')`

  [6643](yarnpkg/yarn#6643) - [**Maël Nison**](https://twitter.com/arcanis)

## 1.12.2

This release doesn't actually exists and was caused by a quirk in our systems.

## 1.12.1

- Ensures the engine check is ran before showing the UI for `upgrade-interactive`

  [6536](yarnpkg/yarn#6536) - [**Orta Therox**](https://github.com/orta)

- Restores Node v4 support by downgrading `cli-table3`

  [6535](yarnpkg/yarn#6535) - [**Mark Stacey**](https://github.com/Gudahtt)

- Prevents infinite loop when parsing corrupted lockfiles with unterminated strings

  [4965](yarnpkg/yarn#4965) - [**Ryan Hendrickson**](https://github.com/rhendric)

- Environment variables now have to **start** with `YARN_` (instead of just contain it) to be considered

  [6518](yarnpkg/yarn#6518) - [**Michael Gmelin**](https://blog.grem.de)

- Fixes the `extensions` option when used by `resolveRequest`

  [6479](yarnpkg/yarn#6479) - [**Maël Nison**](https://twitter.com/arcanis)

- Fixes handling of empty string entries for `bin` in package.json

  [6515](yarnpkg/yarn#6515) - [**Ryan Burrows**](https://github.com/rhburrows)

- Adds support for basic auth for registries with paths, such as artifactory

  [5322](yarnpkg/yarn#5322) - [**Karolis Narkevicius**](https://twitter.com/KidkArolis)

- Adds 2FA (Two Factor Authentication) support to publish & alike

  [6555](yarnpkg/yarn#6555) - [**Krzysztof Zbudniewek**](https://github.com/neonowy)

- Fixes how the `files` property is interpreted to bring it in line with npm

  [6562](yarnpkg/yarn#6562) - [**Bertrand Marron**](https://github.com/tusbar)

- Fixes Yarn invocations on Darwin when the `yarn` binary was symlinked

  [6568](yarnpkg/yarn#6568) - [**Hidde Boomsma**](https://github.com/hboomsma)

- Fixes `require.resolve` when used together with the `paths` option

  [6565](yarnpkg/yarn#6565) - [**Maël Nison**](https://twitter.com/arcanis)

## 1.12.0

- Adds initial support for PnP on Windows

  [6447](yarnpkg/yarn#6447) - [**John-David Dalton**](https://twitter.com/jdalton)

- Adds `yarn audit` (and the `--audit` flag for all installs)

  [6409](yarnpkg/yarn#6409) - [**Jeff Valore**](https://github.com/rally25rs)

- Adds a special logic to PnP for ESLint compatibility (temporary, until [eslint/eslint10125](eslint/eslint#10125) is fixed)

  [6449](yarnpkg/yarn#6449) - [**Maël Nison**](https://twitter.com/arcanis)

- Makes the PnP hook inject a `process.versions.pnp` variable when setup (equals to `VERSIONS.std`)

  [6464](yarnpkg/yarn#6464) - [**Maël Nison**](https://twitter.com/arcanis)

- Disables by default (configurable) the automatic migration of the `integrity` field. **It will be re-enabled in 2.0.**

  [6465](yarnpkg/yarn#6465) - [**Maël Nison**](https://twitter.com/arcanis)

- Fixes the display name of the faulty package when the NPM registry returns corrupted data

  [6455](yarnpkg/yarn#6455) - [**Grey Baker**](https://github.com/greysteil)

- Prevents crashes when running `yarn outdated` and the NPM registry forgets to return the `latest` tag

  [6454](yarnpkg/yarn#6454) - [**mad-mike**](https://github.com/mad-mike)

- Fixes `yarn run` when used together with workspaces and PnP

  [6444](yarnpkg/yarn#6444) - [**Maël Nison**](https://twitter.com/arcanis)

- Fixes an edge case when peer dependencies were resolved multiple levels deep (`webpack-dev-server`)

  [6443](yarnpkg/yarn#6443) - [**Maël Nison**](https://twitter.com/arcanis)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants