Package JSON Demystified - The 'Workspaces' Keyword
HTML-код
- Опубликовано: 12 сен 2024
- In this Javascript tutorial on NPM Package.JSON we look at the 'WORKSPACES' keyword and how it helps us manage monrepo setups
With a monrepo we have maintenance and tasks that can be aided by ceratin tools. The workspaces feature of NPM is one such tool in that in allows us to NPM link all the sub packages to the main root package in our repo. This takes away the manual work associated with this. Workspaces can also help automate running of scripts against all of the sub projects. So it provides a nice bit of automation for us and can be built upon by other tools. So if the basic functionality is not enough then we can also incorporate other tools that build upon this such as 'Lerna'
Thank you very much for this video, I can listen to you for hours. I think your channel is really underrated.
Maybe adding more quality videos like this one will help you grow.
Thanks Alan, much appreciated 🙂
Really great teacher, thanks!
Glad it was helpful AJ - cheers Mark 🙂
Great explainer. Thanks!
Glad it was helpful Phil 🙂 Cheers Mark
Great, thanks for this video. I do have a question. Is the parent worskspace individually source controlled from it's child packages? The first thing that came to mind was, how do I check in workspace items, without also checking in the child packages? Do I have to add the root of the child packages ('let's call this the packages folder) to the gitignore, or is this part of the functionality of npm workspaces, to recognise that the child packages are independently source controlled from the workspace (actually, like git submodules)? Thanks.
Good question! I'm not 100% sure to be honest. As I'm aware there is no granularity in a Github monorepo so nothing there to define checking in only one of the packages . That said I would imagine the process would be to create a new branch for any dev you perform on a particular package and that gives you the isolation required. So dev on other packages is also contained within their own branches and you can merge back to Master and push without pushing the other packages also. Sounds good? maybe! but not tried it out myself :-) Cheers Mark
Great video that explains the essence of workspaces with simple examples. Thanks for that.
Got a question though, noticed "npm i" installs only one "node_modules" in the root directory, I also tried "yarn install" using the same folder structure and it behaves the same as your example.
But I saw some other projects with yarn + workspaces, "yarn install" installs one "node_modules" for each subdirectory. In the context of the example, "yarn install" may create 3 "node_modules" in root directory, ./packages/cli/, and ./packages/cli2/ respectively. Any idea why? Or if extra configuration to enable/disable "node-modules" creations? (Hope I've made my question clear enough.. ) Thank you.
Is each package just as easy to publish to npm, as if it were standalone?
Hi Michael, I'm thinking so yes, each package has its own package.json, so should be BAU. Cheers Mark 😀