ignore-optional flag works not like expected

[medialwerk]

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

What is the current behavior?
yarn install --ignore-optional tries to install also optional dependencies of sub modules. The while install process fails if one of the optional module installation fails.

What is the expected behavior?
To skip the optional dependencies of sub modules or to continue on errors.

Please mention your node.js, yarn and operating system version.
Node 7.5.0, Yarn v0.19.1, Ubuntu 14.04

[boneskull]

👍 here. --ignore-optional does not work with install, but only add. e.g.:

• If I run yarn add ascoltatori --ignore-optional in my project, then ascoltatori's optional packages will not be installed.
• If I run yarn add bluebird thereafter, Yarn attempts to install ascoltatori's optional packages (ouch!).
• If I run yarn install in my project, Yarn attempts to install ascoltatori's optional packages.

Using yarn config to set the ignore-optional flag seems to have no effect on this behavior; I imagine it only works if my project has optional dependencies.

Here's how I'd expect things to work:

If this flag is set in a local .yarnrc, I would expect optional dependencies to be ignored upon install or add for my project and everything listed in my lockfile. If global, then this behavior should apply to any usage of Yarn in any directory.

If the flag is not set .yarnrc, then yarn add foo --ignore-dependencies should append information to the lockfile which tells Yarn to ignore dependencies for package foo only. Upon yarn add bar, or a fresh yarn install, Yarn should respect this flag. I have no idea if this is feasible.

Thanks!

[RichiCoder1]

Just ran into. Was surprised it didn't work for install.

[bestander]

Optional deps should still be resolved and saved in lockfile but they should not be installed with this flag.
Looks like indeed Yarn checks for this flag only on top level

[bestander]

@BYK, I've reaised the priority to get it on your radar, feel free to lower as you see fits.
To others, a PR will be welcome

[arcanis]

rm -rf foo

(
    mkdir -p foo/a && cd foo/a
    echo '{"name":"a", "version":"1.0.0", "dependencies": {"b":"file:../b"}}' > package.json
)

(
    mkdir -p foo/b && cd foo/b
    echo '{"name":"b", "version":"1.0.0", "dependencies": {"c":"file:../c"}}' > package.json
)

(
    mkdir -p foo/c && cd foo/c
    echo '{"name":"c", "version":"1.0.0", "optionalDependencies": {"d":"file:../d"}}' > package.json
)

(
    mkdir -p foo/d && cd foo/d
    echo '{"name":"d", "version":"1.0.0", "dependencies": {}}' > package.json
)

(
    cd foo/a
    ~/yarn/bin/yarn --ignore-optional

    tree
)

[SuhairZain]

@bestander Is there any way to avoid optional dependencies being added to the lockfile? We have an issue with the strip-json-comments package. This is a dependency to another optional dependency. For now, what we're doing is always running yarn --ignore-optional instead of yarn, but we'd very much like to get rid of this dependency from the lockfile if possible. Are there any flags to do that?

[patcon]

Optional deps should still be resolved and saved in lockfile

@bestander So if we have a private git repo that not everyone can access, optional dependencies are not where we should keep that? (yarn tried to ls-remote it and fails)

[BYK]

@patcon for your builds to be deterministic, at least all recursive dependency information for all the packages used should be available to all yarn builds (or you can opt for locking the lock file with --frozen-lockfile for everyone except who has access to this repo.

[patcon]

Interesting... I wonder if it might be possible to manually supply package.json files somehow... or is that too hacky? As in, YES, I am 100% in favour of deterministic builds taking absolute precedence for all that they unlock, but seems awkward to not be able to circumnavigate a private repo for optional/dev[/peer?] dependencies.

Or perhaps this is already possible with resolutions... with a minimal local file package in-repo that's only the package.json https://yarnpkg.com/lang/en/docs/package-json/#toc-resolutions

If you feel there's merit in this, please just say the word and I will poof a new issue :) But no worries if not. Thanks so much for your consideration

(At the very least, I suppose I'm just banking the idea above in case some future traveller is looking for a possible solution :)