wclr / yalc

Work with yarn/npm packages locally like a boss.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Resolve dependencies of a package with a specific value

paulobmarcos opened this issue · comments

Hey @wclr!

Issue

Yalc by default resolves the workspace: protocol in dependencies.

That got me thinking if we couldn't also find a way to define how we want this dependency to actually be resolved.

I have a use case where it would be useful for a dependency to be resolved from workspace: to link: or a portal: instead of the actual package version.

The scenario is as follows:

  • packageA and packageB live in a yarn workspaces repository.
  • packageB has a workspace: protocol dependency on packageA.
  • I want to test packageB in an app repository.
  • I use yalc add packageA --pure to add packageA to the app repository.
  • I use yalc add packageB --link to add packageB to the app repository.
  • Both packageA and packageB will exist in the .yalc folder in the app repository.

The end result would, by default, resolve the workspace: to the actual version of packageA.

However if we try to yarn install the app, yarn will try to install packageB and it's dependencies - this will cause it to fail because it can't really resolve the packageA dependency version from nowhere.

Solution

What if we could specify a different way to resolve the workspace protocol?

In this case I would like for packageB to have a different protocol pointing the package locally in the .yalc folder, instead of workspace::

From:

/* .yalc/packageB/package.json */

"dependencies": {
   "packageA": "workspace:*"
}

To:

/* .yalc/packageB/package.json */

"dependencies": {
   "packageA": "link:../packageA"
}

Do you think there could be an option where we can define how to resolve the workspace: protocol in a more specific manner?


Portal instead of Link

What I would really like to use would be the portal: protocol instead of link:.
I have created a PR to accept a portal option while doing a yarn add: #219

However, I believe link is still good enough to describe the issue here.