yarn install --flat - Automatic Choice

[shellscape]

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

What is the current behavior?
yarn install --flat asks the user which version of a module they would like, if there is a conflict.

Please mention your node.js, yarn and operating system version.
node v6.8.1
npm v3.10.8
yarn v0.16.1

yarn install --flat is wonderful in that it asks the users which version of a dep they want to install. However, it would be immensely useful for automation environments, to allow for an option to direct yarn to automatically assume the newest version.

[polizz]

If this is a feature that should be implemented, I can work on it.

[davidbarratt]

Composer does this really well. It actually always resolves it's own version, and gives you options:
https://getcomposer.org/doc/04-schema.md#prefer-stable
and
https://getcomposer.org/doc/04-schema.md#minimum-stability

You can also set this on the CLI
https://getcomposer.org/doc/03-cli.md#update

If Composer can't resolve a version, it doesn't have you choose, it just throws an exception and explains why there is no suitable version and forces you to resolve this in your project, or in a dependency. It also resolves the dependency versions every time you run update rather than storing this somewhere. I think this is a much better behavior than asking the user to resolve the dependencies.

[shellscape]

For reference: I put together a gulp plugin that examines an install tree prior to installing to look for any discrepancies (aka version conflicts) between modules in the entire tree. https://github.com/shellscape/gulp-version-conflicts is what I came up with and while it's quite quick, it's still another step before we get to running npm or yarn.

[aij]

@shellscape I was looking for this same option, but I only see it as being useful for the initial transition to yarn flat mode.

As I see it, automated environments should be using yarn.lock rather than trying to resolve dependencies nondeterministically. (Though perhaps I'm just not understanding your use case.)

FWIW, I did find the unexpected interactivity rather surprising. The ordering of the options also seems somewhat arbitrary. (I didn't look into where the order comes from though.)

It would be nice if at least option 1 was always the newest version (or best guess through some smarter heuristic?), then I could run yes 1 | yarn --flat as a reasonable starting point. (Though a dedicated option may be easier for more people.)

[davidbarratt]

I expected this to work like npm dedupe

[aij]

@davidbarratt No, flat mode will install a single version of each package (like bower AFAICT). npm dedupe only deduplicates non conflicting dependencies. (Which seems to only be for somewhat cleaning up after it's non-reproducibility?)

For example, with yarn --flat I get a single copy of babel-runtime. If instead I run npm install I get 59 copies. After running npm dedupe that is still 59 copies.

[davidbarratt]

@aij Ah yes. I agree. Let me rephrase, in my opinion it should resolve everything to a single version, and if it can't, it should throw an exception and explain the conflicts rather than making you decide.

[beejei]

Hi, is there any changes for this?

[jaen]

Not having this is quite vexing, I actually have to write a script that tails the output of yarn, feeding it to a state machine that can answer those questions automatically to get this feature : C

[aliatsis]

Can there at least be a config option to auto-select the first/highest version in the specified range?
Not having this is a major issue for my workflow.

[buu700]

In case it's helpful to anyone, here's the temporary workaround I'm using until this is resolved:

read -r -d '' modules <<- EOM
	@angular/animations
	@angular/cli
	@angular/common
	...
	xkcd-passphrase
	zombie
	zone.js
EOM


cd ..
yarn add compare-versions
cd -

script -fc "
	while [ ! -f yarn.done ] ; do
		answer=\"\$(node -e 'console.log(
			(
				(
					fs.readFileSync(\"yarn.out\").
						toString().
						split(\"Unable to find a suitable version\")[1]
					|| \"\"
				).
					match(/resolved to \".*?\"/g)
				|| []
			).
				map((s, i) => ({index: i + 1, version: s.split(\"\\\"\")[1]})).
				reduce(
					(a, b) => require(\"compare-versions\")(
						a.version,
						b.version
					) === 1 ?
						a :
						b
					,
					{index: \"\", version: \"0\"}
				).index
		)')\"

		if [ \"\${answer}\" ] ; then
			echo > yarn.out
			echo \"\${answer}\"
		fi
	done | bash -c '
		yarn add \
			--flat \
			--ignore-engines \
			--ignore-platform \
			--ignore-scripts \
			--non-interactive \
			$(echo "${modules}" | tr '\n' ' ') \
		|| \
			touch yarn.failure

		touch yarn.done
	'
" yarn.out

if [ -f yarn.failure ] ; then
	exit 1
fi

rm -rf ../node_modules ../package.json ../yarn.lock yarn.failure yarn.out

As I see it, automated environments should be using yarn.lock rather than trying to resolve dependencies nondeterministically. (Though perhaps I'm just not understanding your use case.)

I can't speak to anyone else's use case, but in my case we have a script that generates and commits a new package.json and yarn.lock with the latest versions of a list of modules, after which point yarn.lock is used as you suggest.

[ds300]

Bash scares the hell out of me so I also made a script to automate this, but in javascript: https://gist.github.com/ds300/158250f230d1825af8a3edd6e7af9cc0

[rally25rs]

In Bower, it uses a config property named resolutions in the bower.json file to remember what version to use when there is a conflict:

  "resolutions": {
    "jquery": "1.12.4"
  }

That would tell it to always chose [email protected] when multiple versions could be selected.
Yarn could follow that pattern.

[mrmachine]

This is preventing adoption of yarn here. Yarn appears to require a tty with --flat even before it has discovered that there are actual conflicts (just in case it eventually encounters a conflict), and even when --non-interactive is also specified. A google search yielded a bunch of results that were ultimately a waste of time in diagnosing this limitation.

[tomkel]

This feature is necessary to run --flat in CI type environments

[rally25rs]

For anyone who would like to try to implement this feature, it might be helpful to write up an RFC and post it over on https://github.com/yarnpkg/rfcs where there can be some discussion as to what the correct behavior should be. 👍

[bys92]

For Enterprise Software this a must have feature. We currently also think about to switch back to NPM because this breaks our CI plans.

Is there already a RFC or a Plan how to do this ?

[TheoXD]

At least sort the damn choices by version, so I can just press first option 100 times and at least see if it's going to work or not. Currently wasting time trying to flatten polymer dependencies.

[Mouvedia]

Shouldn't this have the high-priority label ?
This is in the top 10 issues if you sort by 👍

[GongT]

please make yarn install --flat --json work!
And then there will be tons of package can resolve the automatic problem.

[shellscape]

Mind-bottling that this is still an open issue after two years.

[pmespresso]

someone should bounty this on gitcoin.co

[damianobarbati]

+1 for this 🙏🏻

Did anybody find a solution to auto-install latest versions when running --flat?

[davidtranjs]

Me too, so annoying @@

[Danzabar]

If this is a feature that should be implemented, I can work on it.

@polizz You still working on this?

[damianobarbati]

@polizz 🙏🏻

[GongT]

I created a brand new sh*t on npm: @gongt/flat-yarn-install

[DerekZiemba]

This also annoys me greatly. So I created https://github.com/DerekZiemba/yarn-V2-workspaces-simple-monorepo/blob/classic/build/yarn-install-flat.js

Should be able to drop that file in anywhere. It auto-installs dependencies globally such as yarn, semver, and node-pty`. So not only can it do --flat, but it'll initialize a brand new repo that doesn't have any node_modules installed yet.

There's a readme here https://github.com/DerekZiemba/yarn-V2-workspaces-simple-monorepo#automated

[Bec-k]

any updates on this one?

[telamon]

My takeaway from reading this issue.
Defining behaviour is sensitive/complex; Needs to go through RFC pipe 👍

But this proposal would actually help tremendously without a negative impact:

It would be nice if at least option 1 was always the newest version (or best guess through some smarter heuristic?), then I could run yes 1 | yarn --flat as a reasonable starting point. (Though a dedicated option may be easier for more people.)

Can I have this please? :)