That will give you the following output: > test > echo 'all package-a tests passed!' all package-a tests passed ! > test > echo 'all package-b tests passed!' all package-b tests passed ! You can run all the “test” scripts at once by adding the -workspaces (plural) to your npm run command: # Run "test" script on all packages npm run test -workspaces # Tip - this also works: npm run test -ws In fact, it’s on that file that you define the location where your packages live.Įdit the root package.json to reference your packages: //. Notice you still need a package.json file in the root of your repository, even if it has no dependencies. ├── package.json └── packages ├── package-a │ └── package.json └── package-b └── package.json You can use a similar structure as the ones showed before as a starting point for playing around with workspaces. To update, run this command on your terminal: npm install -g you install Node.js 15 today, it should already come with npm 7. You can try out Workspaces today by updating your npm to version 7. These are just a few examples to illustrate how the new dependency resolution works on Workspaces, there’s certainly a lot more happening under the hood. ├── package.json └── packages ├── package-a │ └── package.json └── package-b │ node_modules # `node_modules` is created inside the package │ └── lodash # This is `lodash` version 3.x └── package.json ├── node_modules │ ├── lodash # This will be `lodash` version 4.x │ └── #. ├── package.json └── packages ├── package-a │ └── package.json # Dependencies: └── package-b └── package.json # Dependencies: running npm install, you will get the following result. For example, suppose package-a uses while package-b is still on. If you have packages using the same dependency but on different versions, npm will create a node_modules folder inside of one of the packages. ├── node_modules │ ├── lodash # `lodash` is installed in the root `node_modules/` │ ├── package-a # package-a is symlinked │ └── package-b # package-b is symlinked ├── package.json └── packages └── #. ├── package.json └── packages ├── package-a │ └── package.json # Dependencies: `lodash` └── package-b └── package.json # Dependencies: `lodash`, `package-a`Īfter running npm install, your node_modules folder will look like this. If two of your packages depend on each other, they get the reference from there.įor example, if you have this structure. Your packages (the ones you created) also get symlinked in the root node_modules folder. This is done for performance reasons: if a dependency is shared by multiple packages, it gets saved only once in the root. Now, when you run npm install in a multi-package repository, npm’s dependency tree manager is smart enough to scan your folders looking for all dependencies to install.ĭependencies are hoisted, meaning they get installed in the root node_modules folder. I’ve also provided a repository on GitHub with some sample code from the examples. In this post, you will see how npm Workspaces work, how to get started, and a comparison with other Workspace implementations. This special type of repository is known as a monorepo. In projects like this, you usually have a complex dependency tree, with many packages depending on each other. You can find similarities between all three Workspace implementations.īut what are Workspaces for? Workspaces help us managing repositories with multiple packages - more than one package.json file. In fact, npm is not trying to reinvent the wheel. Other package managers such as Yarn and pnmp already ship with Workspaces for quite a while now. The 7th version of the package manager introduced Workspaces. The newest major release of npm, launched in October 2020, came out with a very anticipated feature (at least for me).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |