Yarn: Allow packages to specify that they must be flattened in package.json

[justinfagnani]

Rather than just a kpm flag, it'd be great for a package to specify that it must me installed flattened.

This will be the case for packages that use native ES6 module imports and/or HTML imports, both of which require importing other packages via URL. The standard practice is for all packages to be installed as siblings and refer to each other by ../other-package/... paths. All Polymer element packages will need to be installed flat.

Being able to specify this in package.json will allow for a top-level package to always install flat, and for a dependency to trigger a warning if it's not installed in a flat installation.

[FredKSchott]

+1, I've been playing around with the flattening behavior and the --flat flag leads to a very confusing user experience:

1. If a package author writes their package to rely on a flat dependency tree, the code fails to run properly when a user runs a default kpm install unless kpm.lock file exists (maybe not an issue?)
2. If a package author writes their package to rely on a flat dependency tree, it can be installed as a dependency in a non-flat dependency graph without any warnings or errors. It will then fail to run properly as a dependency.
3. If a user creates a kpm.lock file via a --flat install, future packages saved without the --flat flag won't ask for resolutions and lead to a non-flat (partially flat) lockfile. Only fixed by rerunning kpm install --flat --save.
4. There is no way to unflatten a kpm.lockfile, besides removing it and re-creating from scratch or manually removing resolutions from the file.

In my experience so far, flat would be a much better fit as a package.json property so that it's flat status is explicit and not easily changed via calls to kpm install $PACKAGE.

[sebmck]

I think a flat flag for root level installs is a good idea but the introduction of it to transitive dependencies that rely on the flat behaviour is going to lead to incompatibilities with the npm ecosystem.

[justinfagnani]

The incompatibility is already there - the package inherently relies on flat installs. The flag is just a signal for that.

[sebmck]

We can only have the entire tree flattened and don't support having specific branches. Given these constraints I think the optimal behaviour would probably be:

1. Implicit --flat flag if the root package.json has flat: true.
2. If a transitive dependency has flat: true in it's package.json but you aren't running a flat install then we throw an error (or warning).

[FredKSchott]

^^^ This works for us! As Justin mentioned all of these packages will be specifically frontend and built to rely on a flat dependency tree for loading, so erroring on a non-flat install should be fine & rarely encountered.