yarnpkg
[Feature] Expected `yarn link ...` does not change package.json and lockfile
- [ ] I'd be willing to implement this feature (contributing guide)
- [ ] This feature is important to have in this repository; a contrib plugin wouldn't do
Describe the user story
Developing multiple packages in the case of local non -Monorepo, I will last long to perform Yarn Link, but this configuration should not be uploaded to Git.
The current version of yarn will change the package.json and lockfile during yarn link, which will affect my git operation.
Describe the solution you'd like
Can you provide a file like yarn.linked to indicate linked Instead of changing package.json? So I can add the file(yarn.linked) in ignore.
Describe the drawbacks of your solution
No thought, just trying to suggest.
Describe alternatives you've considered
Like yarn v1, global effect?
There was an attempt made already 2019, see #90
Oh, thanks.
I looked at it, it still didn't seem to be resolved, so sad 😢.
Yeah this surprised me as well. I looked into a solution because "yarn link" v1 doesn't work correctly if you want to link a scoped package from a link dir. I thought the v3 version would solve this, however it changes package.json which isn't really a good solution if you intend to push the result.
Until this problem is resolved, it seems that we will have to continue using yarn v1 😢.
@WhiteMinds I think, you can still upgrade to latest berry version 3.x with the following workaround, doing no harm to package.json nor tsconfig.json:
-
cd <project-a> - YARN_IGNORE_PATH=1 yarn link
-
cd <project-b> - YARN_IGNORE_PATH=1 yarn link project-a
@WhiteMinds I think, you can still upgrade to latest berry version 3.x with the following workaround, doing no harm to package.json nor tsconfig.json:
Thank you. It works great! Now I can go from classic link to berry and go from berry link to classic.
I tried a solution like the one from @Venryx mentioned in #90 (yarn-vtools), but was disappointed to learn that this still changes your yarn.lock file.
It'll take some time, but it's definitely something I'd like to address in the next major or the one after. Generally I'd like to extend the concept of workspaces to external repositories, although I'm not fully sure yet how this would materialize.
