feat: add hoist command

[JamieMason]

hoist

Take a property from multiple package.json files and merge them into the target package.json. When
hoisting dependencies and multiple sources contain the same dependency, the newest version will be
used. When hoisting scripts with the same name, they will be namespaced on the target like so
"build:packagename".

Options

-s, --source [pattern]  glob pattern for package.json files to read from
-t, --target [pattern]  glob pattern for package.json files to write to
-p, --prop [name]       path to property to hoist
-e, --exclude [name]    path to property to exclude from hoisting
-i, --indent [value]    override indentation. defaults to "  "
-h, --help              output usage information

Examples

# uses packages defined in lerna.json as default sources and ./package.json as default target
syncpack hoist --prop "devDependencies"
# nested properties can be hoisted like this
syncpack hoist --prop "devDependencies.gulp"
# properties can be excluded like this
syncpack hoist --prop "devDependencies" --exclude "devDependencies.jest"
# uses packages defined by --source and --target when provided
syncpack hoist --prop "devDependencies" --source "apps/*/package.json" --target "package.json"
# multiple sources can be provided like this
syncpack hoist --prop "devDependencies" --source "apps/*/package.json" --source "core/*/package.json"
# multiple targets can be provided like this
syncpack hoist --prop "devDependencies" --source "packages/foo/package.json" --target "packages/bar/package.json" --target "packages/baz/package.json"
# multiple properties can be provided like this
syncpack hoist --prop "devDependencies" --prop "scripts"
# indent package.json with 4 spaces instead of 2
syncpack hoist --prop "devDependencies" --indent "    "

[AlexHayton]

This sounds really useful! Would also need a list of deps not to hoist (e.g. jest)

[JamieMason]

Thanks @AlexHayton, I've written up a spec above based on our ideas so far.

[AlexHayton]

Spec looks good to me

[ericontilt]

I'd be very interested in this feature as well. I found syncpack while looking for a tool to pull dependencies to peerDependencies across a monorepo. Looks like it would be a very similar, yet maybe distinct command. What do you think?

[JamieMason]

Hi @ericontilt 👋

a tool to pull dependencies to peerDependencies across a monorepo

do you mind giving a small example of what you mean please? I think I follow but there are a couple of ways to interpret it that's all. Thanks!

[ericontilt]

do you mind giving a small example of what you mean please

Sure! Suppose I have an app (A) which uses ui component packages (C1, C2, .. Cn) which are developed in a monorepo. And suppose these components are not properly organized in a way that all packages use, e.g. angular as a dependency, instead of as a peerDependency.

Now I'd like a way to look at the dependencies of package.json of A, and use those to determine which dependencies of C1, C2, .. Cn can be moved to peerDependencies in their respective package.json files.

I hope this makes it a bit more clear. If not, by all means let me know. I'd be happy to make a pull request as well, if we settle on the concept.

[JamieMason]

I'm not confident I totally understand yet but I think this would be a different command to hoist, but I could be wrong about that and I'd be happy adding another command if we think it would be useful.

The main use case for hoist is to take devDependencies or scripts from multiple ./packages/*/package.json and to move and dedupe them into the ./package.json.

In the command you describe it sounds like the sources are also the targets? we read multiple sources, do some analysis, and then write to the same files? ie moving dependencies.angular to peerDependencies.angular is that right? If you could add some pseudo code or examples of what the syncpack ... --arg --etc might look like that should help me get up to speed.

Thanks a lot Eric.

[ericontilt]

I also don't think it's exactly the same, so a different command is probably needed with very similar specs. Or a flag on the hoist command maybe.

In the command you describe it sounds like the sources are also the targets?

That's not quite what it would be doing. Rather, there would be a single source package.json, and multiple targets within which packages would be hoisted from dependencies to peerDependencies (and devDependencies).

I'll write up a spec asap when I find the time in the course of the next days.

[JamieMason]

Hey @ericontilt do you still want the feature we were discussing?

[ericontilt]

Hi Jamie. I'm no longer working in this area at the moment. So there is no need for me to follow up on this. Thanks.

[JamieMason]

Closing in favour of using $ better-deps --hoist-dev-deps by @ecraig12345 👍🏻

[ecraig12345]

@JamieMason Haha thanks, though better-deps is definitely still early/experimental stage, and I'm not sure long-term whether it makes sense as its own tool or would be better to combine the functionality into one or more existing tools (such as syncpack). I hadn't thought about hoisting as something syncpack could handle, but I can see how that would make sense.