Skip to content
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

Publish --exact & removing symlinks #927

Closed
cloudratha opened this issue Jul 19, 2017 · 2 comments
Closed

Publish --exact & removing symlinks #927

cloudratha opened this issue Jul 19, 2017 · 2 comments

Comments

@cloudratha
Copy link

I'm currently evaluating the use of Lerna for an upcoming project.

Adding the exact flag during publish sets the dependency modules to the exact version you are publishing.

After Publishing I would expect that the symlinks in the packages be replaced with the current state of the package. This behaviour is honoured when bootstraping a version which is lower than the current package version, pulling the lower version from npm.

Is it reasonable to say that versions that match the current version, preceded with a caret, should be symlinked during bootstrap. And that exact matches should copy the package across (or npm install). I'm sure this could be, yet another flag, or configurable lerna.json option.

So if I would like to re-add the symlink to a previously exact match version dependency I could just add the caret in the package.json in the package and re-boostrap.

I've tried to find similar issues, so I'm sure I'm either missing something or this is an unique usecase.

Thoughts?

@evocateur
Copy link
Member

What you describe isn't really how lerna was intended to work. Whether or not you use --exact doesn't change the fact that lerna will always symlink local packages with a matching version. After publishing, the "current state of the package" is exactly what's on disk.

Yes, you can install non-matching versions of monorepo siblings, but that's not really meant to be a common part of the workflow. It's more of an escape hatch for packages that you don't have time to update to a new breaking API or somesuch.

@lock
Copy link

lock bot commented Dec 28, 2018

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Dec 28, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants