I configured 2 workspaces in package.json e.g example and gatsby-theme but later I found I was actually developing a gatsby-starter so I removed the example workspace that depended on the latter workspace from package.json.
I wonder if I moved all files from gatsby-theme/ to the project root directory and overwrote the package.json and other files with gatsby-theme's, does it become a project that could be managed with both npm and yarn?
Related
I have a mono-repo that contains the main code, and some custom packages as workspaces.
so my directory structure is like this
- mainRepo
-- directories of main project
-- /node_modules
-- /packages
--- my-foo-package
---- /node_modules
so since the workspace (my-foo-package in this case) has its own node_modules, every dependency that it has is going to be there
but main repo also needs the workspace dependencies too, to be able to import codes from workspace package
but after i added the workspace package, linked it and added it to main repo dependencies and ran yarn install i still cannot see the dependencies of workspace package in roo node_modules
is there any step missing?
I am using Yarn's Workspaces feature to manage a monorepo. Some of the individual workspaces have their own dependencies defined in their own package.json, however I also have some shared dependencies (some are for testing the whole repo, some are used by all the workspaces). How do I declare these the correct way?
If I try to add them to the root package.json, Yarn gives me a warning. But adding the same dependency to all n workspaces (there are a lot and it's liable to grow) seems tedious and hard to maintain when upgrading dependencies.
Is the right thing to do to add the shared dependency (say, typescript, or jest or serverless) to every single individual workspace?
Using Yarn 1/classic.
I found also Yarn Workspaces: How and where should I install my dependencies? but it's unanswered
Yarn workspaces shared dependencies talks about using peer dependencies but the user is experiencing trouble
After a half-day search and trying, I found multiple ways to manage shared dependencies
1. Sync dependency version with syncpack
https://github.com/JamieMason/syncpack/
Given the fact that yarn workspaces will share the dependencies if their versions are the same (see https://classic.yarnpkg.com/lang/en/docs/workspaces/), all we have to do is to keep the dependency versions in sync to make dependencies sharing, which is exactly what syncpack does.
I found this is the least harmful way to make sharing dependencies works, while other methods require some degree of twisting package.json.
2. Use peer dependencies
For each package, set sharing dependencies as peerDependencies with version “*”, and set root workspace set the real dependencies. For example:
# ./package.json
{
...
"workspaces": ["packages/*"],
"dependencies": [
"some-lib": "^1.0.0",
]
}
# ./packages/pkg-a/package.json
{
...
"peerDependencies": [
"some-lib": "*",
]
}
and yarn install at workspace root.
3. Share script (require yarn v2)
See https://yarnpkg.com/getting-started/qa#how-to-share-scripts-between-workspaces
Miscellaneous
yarn provides workspace cli to add/remove package, see https://classic.yarnpkg.com/lang/en/docs/cli/workspace/
yarn workspace awesome-package add react react-dom --dev
yarn workspace web-project remove some-package
I'm using yarn with monorepos that contain several packages. For examples packages foo and bar might be located in repo/foo and repo/bar within the monorepo root repo. The problem is that I sometimes accidentally run yarn without parameters in the repository root instead of the packages directories. This creates a repo/node_modules directory and a repo/yarn.lock file. Can I somehow prevent yarn from creating node_modules and yarn.lock in the repository root directory?
I have a common (or not so coomon) scenario for yarn workspaces and didn't find the right guide for me online.
yarn workspaces look like that:
- monorepo
- packages
- client
- admin
- theme
- lib
Client is used as our endusers, it is a react project
Admin is used as backoffice for admin users and it is build in react too
Theme is used for all the UI kit (components) and storybook. We use the UI kit in client and admin
project and this is classic "monorepo style" (lerna) to share components between 2 projects. This folder should be shared only for this project.
Lib is used for all API and shared "Business logic" between multiple projects. I have 4 project which use the same lib functionality for API requests, Authentication, Redux and more.
Additional information:
monorepo is root repository with .gitmodules
Each sub folder is a different git repository
We use workspaces in order to have easy development on theme and on the client and admin project on the same time.
Questions:
We run yarn start only in client project and admin project. Both projects are using the same theme and same lib functionality. Because the lib is shared with other projects, it is updated on a weekly base:
How I can prevent from it to be updated from project to project? should I work with tags in git repository or should I remove lib from the monorepo worksapce and to work with it as npm package (the whole point is to have easy development process when we change the lib file we do not need to npm update it again and again.
If lib will be npm package, How can I tell monorepo to use workspaces when I run yarn start and to use the npm version when I run yarn build?
Please advice on the best practices for this scenario.
Thanks in advance,
Leo.
FINAL ANSWER:
I found the best solution for me and I tried it for 6 weeks during development (best practice).
I ended up with this structure:
monorepo // git MAIN repository
packages
client // git sub repository
admin // git sub repository
theme // git sub repository
lib // git sub repository
The client and admin use the theme as yarn workspaces https://classic.yarnpkg.com/en/docs/workspaces/
lib is used as Git npm package with git+ssh://git#gitlab.com:xxxx/xxx/lib.git#v1.0.1
The main/sub repositories structure gives me the ability the manage version control for each project separately and on the same time to use shared "theme" (workspaces) and "lib" core (npm) by versions.
Tip:
For easy development I recommend to add the lib as yarn workspace because when we run yarn start it hot reload the changes in real time. When we do yarn build we use the lib as npm package with an ssh link.
Good luck!
Leo.
Here is my personal preferences.
- monorepo
- packages
- client
- admin
- core
I think lib can be moved to core, and theme are more like npm package to me.
Here is my problem, I constructed a dockerfile launching yarn install from a folder where a package.json and yarn.lock are present (they have been taken from the project I have to setup yarn dependencies for, this project is inside a deconnected server).
Then, I run bash into container image and uploaded the created folder node_modules, and put it into the deconnected server, where project is present, at root folder project.
But then, when I launched yarn start from root folder, it says that it cannot find rescripts despite of the fact that folder #rescripts is present into node_modules.
I tried NODE_PATH=./node_modules yarn start without any success.
Thanks a lot for your help.
Regards
I think i get what i want with :
https://yarnpkg.com/blog/2016/11/24/offline-mirror/
I create a cache folder with all tar.gz dependencies downloaded.
But if i remove node_modules and yarn.lock, and run yarn install --offline --cache-folder npm-packages-offline-cache/, I got error saying it could not find proper dependance in cache folder. It's like it cannot recognize any tar.gz inside. Any help will be welcome.
Regars