DEV Community

Discussion on: Yarn 3.1 🎃👻 Corepack, ESM, pnpm, Optional Packages ...

Collapse
ekeijl profile image
Edwin • Edited on

What's the best way to handle these special protocols during local development? I use portal: to get the same behaviour as npm link when I want to test an NPM package that I'm working on, but I don't want to commit my package.json file with the portal:../path/etc stuff still inside of it.

I could probably run a special ESLint task on pre-commit to prevent this, but maybe there is a better way?

Collapse
arcanis profile image
Maël Nison Author

At the moment no, we always use the local package.json as a local source of truth, there's no escape from that. For workspaces it's not a problem (since you can just edit them directly, you don't have to play with portals), but for 3rd-party vendors it'd be nice indeed.

Thread Thread
ekeijl profile image
Edwin • Edited on

Alright thanks. Just to clarify, I'm talking specifically about a scenario with Yarn + Lerna (mono-repo with NPM packages). Then I want to test the NPM package inside some other repository so I use portal:.. (or npm link) to set that up. Having all workspaces inside the same repo as you describe would probably work, yes.

Another issue is that Lerna cannot handle Yarn specific protocols (workspace:*), so any Lerna command (lerna version/lerna publish) will fail. This means we cannot use Yarn specific protocols in package.json.