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

Properly skip installation of packages that do not need to be installed (incompatible optionalDependencies for example) #1997

Merged
merged 4 commits into from
Nov 26, 2016

Conversation

mvestergaard
Copy link
Contributor

@mvestergaard mvestergaard commented Nov 23, 2016

Summary

This is a different approach to #1438
It should make sure that packages incompatible with the current environment are not installed.
See #1954 for further motivation

With this change, any optionalDependencies that is incompatible with the environment will be skipped entirely in the install.

Installing a package.json like this on windows or linux:

{
  "optionalDependencies": {
    "fsevents": "*"
  }
}

Will result in an empty node_modules folder, which is the same behavior as using npm.

Test plan

The current test 'root install with optional deps' should test the scenario on anything other than OSX. It uses fsevents which is only compatible with OSX.
To test on OSX you need to modify __tests__/fixtures/install/root-install-with-optional-dependency/package.json to use an optional package that is not compatible with OSX.
CI servers are running linux, so they should be fine.
After running install on a package with a single optional incompatible dependency, node_modules should be empty.

Fixes #1059 #1435

Set the ignore flag using ENVIRONMENT_IGNORE visiblity.
Add the compatbility check as a step of the install hydrate, and call hydrate from install check.
Only set it on the directly affected package, and then ignore those
packages in the hoister
@mvestergaard mvestergaard changed the title Properly ignore incompatible packages using ENVIRONMENT_IGNORE Properly skip installation of packages that do not need to be installed (incompatible optionalDependencies for example) Nov 23, 2016
Copy link
Member

@bestander bestander left a comment

Choose a reason for hiding this comment

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

@mvestergaard would you please add some tests as in your test plan?
We need to make sure that this feature does not break in the future and it is easy to break.
We have platform specific tests for install operation already.

@@ -40,7 +40,7 @@ export async function run(
}

// get patterns that are installed when running `yarn install`
const [, rawPatterns] = await install.hydrate();
const [, rawPatterns] = await install.hydrate(true);
Copy link
Member

Choose a reason for hiding this comment

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

Why is fetch true for a check operation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's for this bit:

await this.fetcher.init();
await this.compatibility.init();

It seems that if the fetcher is not run beforehand, the compatibility check does not have the os and cpu data for each package to properly do the check.

Copy link
Member

Choose a reason for hiding this comment

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

Would this work offline?
I am afraid that initing fetcher may cause a longer check

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good question. I mean if the package is in the cache, it doesn't actually fetch anything, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This happens if the fetch is not a part of the check:

yarn check v0.18.0-0
error chokidar#fsevents not installed
error fsevents#nan not installed
error fsevents#node-pre-gyp not installed
error node-pre-gyp#npmlog not installed
error node-pre-gyp#rc not installed
error node-pre-gyp#tar-pack not installed
error rc#deep-extend not installed
error tar-pack#fstream-ignore not installed
error rc#minimist not installed
error tar-pack#once not installed
error tar-pack#uid-number not installed
error Found 11 errors.

Because the check does not exclude those package due to incompatibility, it expects them to be there, which it shouldn't.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, it makes sense.
For cross platform modules - they are installed in node_modules and could be verified in place but the missing ones could be either "missing" or not installed because they are "optional".

Adding "optional" property to lockfile makes more sense but this needs a discussion involving more people, maybe an RFC?

Copy link
Member

Choose a reason for hiding this comment

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

As a matter of fact, I think there should be a third mode for check - #1934.
I would rather rely on that and the integrity check than the default one

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think adding whether a package is optional to the lock file is enough alone.
You still want it to be installed on an OS where it is supported, but skipped on an OS where it isn't.

Copy link
Member

Choose a reason for hiding this comment

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

I wonder, if package is optional but it failed to install because you don't have a compiler, is it an error or is it ok?

Copy link
Contributor Author

@mvestergaard mvestergaard Nov 24, 2016

Choose a reason for hiding this comment

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

That should be an error.
In my opinion, if it is determined by the OS and CPU requirements of the package that your system is compatible, then any installation error that occurs, are out of the scope of what yarn should handle.

@mvestergaard
Copy link
Contributor Author

@bestander I'll look into adding some tests tonight.
I suppose it kind of needs to be able to catch any issue on all OS?
Relying on fsevents alone will only catch issues on windows and linux, so something alternative has to be done to test on OSX.

@bestander
Copy link
Member

I suppose it kind of needs to be able to catch any issue on all OS?
Relying on fsevents alone will only catch issues on windows and linux, so something alternative has to be done to test on OSX.

You could depend on a fake optional dependency that does not work on any OS.
In install command we use quite a few and save them in the test case' offline morror

@mvestergaard
Copy link
Contributor Author

@bestander How does one go about correctly generating one of those .tgz files found in the mirror-for-offline fixture folders?

@bestander
Copy link
Member

@bestander How does one go about correctly generating one of those .tgz files found in the mirror-for-offline fixture folders?

It is a bit involved.
Just run npm pack on a folder with package.json.
Then you'll need to manually edit yarn.lock file to add sha1 of the file, you could get it with some console.log in tarball-fetcher.js or use a sha1 util on Mac/linux.

@mvestergaard
Copy link
Contributor Author

@bestander I added two tests.
The dep-incompatible package has this in it's package.json "os": [ "invalid" ] so it is considered incompatible on any OS.
It also has a dependency of dep-a. The second test verifies that dep-a is also skipped.

@bestander
Copy link
Member

Great job, @mvestergaard, I'll have a look

@mvestergaard
Copy link
Contributor Author

@bestander Any ETA on next release?

@bestander
Copy link
Member

Saturday-Sunday this week

@friosl
Copy link

friosl commented Apr 28, 2022

Several years later, this worked for me (just adding the "*" to fsEvent in optional packages), I was trying to do CI in aws and the problem was that package :D

@yarnpkg yarnpkg locked as resolved and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Errors from optionalDependency installation scripts should be ignored
3 participants