Yarn workspaces best practice when using shared library

Question

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 

1. Client is used as our endusers, it is a react project
2. Admin is used as backoffice for admin users and it is build in react too
3. 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.
4. 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:

1. 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.
2. 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.

Answer 1

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.

Answer 2

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://[email protected]: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.