[wip] Support yarn "resolutions" #34
Conversation
| packageJSON["files"] = packageJSONFiles | ||
| packageJSON["files"] = packageJSONFiles | ||
|
|
||
| _, err = mergeYarnWorkspaceResolutions(p.C.W.Origin, packageJSON) |
There was a problem hiding this comment.
not keen on the assumption that the package.json is in the workspace root.
I'd rather see this as a config field resolutionsFrom or something. That file would then become AdditionalSource of the yarn package.
There was a problem hiding this comment.
@csweichel I wondered whether there already is an (implicit) relation between leeway and yarn; especially with regards to nested workspaces? Or do we "just" call yarn and are 100% yarn-workspace-agnostic? If there already were such an (implicit) relation it might be nice to make that explicit and derive the package.json for this use case from that.
There was a problem hiding this comment.
Leeway is built on the assumption that all packages of a workspace, including yarn packages, can stand on their own. In that sense, it even assumes that yarn workspaces don't exist.
The only concession we're making to Yarn here is a yarn.lock that resides outside of the package. It's still explicitly listed in the package definition, becomes part of a package's source list and does not imply anything else about the package's structure - just that the yarn lock is outside the package directory. Really, this is something I'd love to get rid of today rather than tomorrow.
Leeway knows nothing about yarn workspaces, as such any assumption of this kind doesn't sit right.
By listing the "resolutions package.json" explicitly, it can become part of the package's source manifest, hence its version. |
|
closing for now. Please re-open if it's still relevant in the future. |
Fixes #12 .
This is a first draft to solve the issues mentioned in #12 (comment).
Open questions: