-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add hoist command #7
Comments
This sounds really useful! Would also need a list of deps not to hoist (e.g. |
Thanks @AlexHayton, I've written up a spec above based on our ideas so far. |
Spec looks good to me |
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? |
Hi @ericontilt 👋
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! |
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. |
I'm not confident I totally understand yet but I think this would be a different command to The main use case for 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 Thanks a lot Eric. |
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.
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. |
Hey @ericontilt do you still want the feature we were discussing? |
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. |
Closing in favour of using |
@JamieMason Haha thanks, though |
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
Examples
The text was updated successfully, but these errors were encountered: