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

[Feature] Replace the workspace: protocol at publish-time #133

Closed
arcanis opened this issue May 7, 2019 · 1 comment
Closed

[Feature] Replace the workspace: protocol at publish-time #133

arcanis opened this issue May 7, 2019 · 1 comment
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@arcanis
Copy link
Member

arcanis commented May 7, 2019

Describe the user story

I want to use the workspace: protocol to enforce my local packages to use my workspaces rather than the remote versions from the npm registry, but that makes them unpublishable.

Describe the solution you'd like

The workspace: protocol should be automatically changed at publish-time. Two cases:

  • workspace:<semver> should become <semver>

  • workspace:<path> should become <version of the workspace at path> (no caret)

Describe the drawbacks of your solution

  • Publishing multiple packages at once still requires [Feature] yarn workspaces foreach features #62 to be implemented (especially the topological sort one, so that publish can work properly).

  • Some people might want to use a caret when transforming the workspace:<path> pattern.

Describe alternatives you've considered

  • We could manually list the replacements in publishConfig (similar to what we do for main and module), but that seems extremely unintuitive.

  • We could use a caret when transforming workspace:<path>, but it's not clear to me what are the implications and I prefer to keep a safe default for now.

  • We could support a caret prefix (workspace:^<path>), but it's not clear whether this is a useful feature so I would table it for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant