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?
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This new workspace flags are 🔥
What's the best way to handle these special protocols during local development? I use
portal:to get the same behaviour asnpm linkwhen I want to test an NPM package that I'm working on, but I don't want to commit my package.json file with theportal:../path/etcstuff 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?
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.
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:..(ornpm 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.