Version:
"packageManager": "yarn#1.22.19"
I have based my project off of the npx create-turbo#latest command.
I have eslint-config-custom and tsconfig projects inside my /packages folder which I reference in my three nodejs apps with:
"tsconfig": "workspace:*",
"eslint-config-custom": "workspace:*",
and in my root package.json workspaces are defined:
"workspaces": [
"apps/*",
"packages/*"
],
Unfortunately, when I run yarn or yarn install in the root folder, yarn pops up telling me to select a matching version:
yarn install v1.22.19
info No lockfile found.
[1/5] Validating package.json...
[2/5] Resolving packages...
Couldn't find any versions for "eslint-config-custom" that matches "workspace:0.0.0"
? Please choose a version of "eslint-config-custom" from this list: (Use arrow keys)
> 0.0.0
Same for the tsconfig dependency, then it only lists versions available for the packages with the same name on the main npmjs.com registry.
How do I get yarn to use the dependency from a workspace?
Additionally, how could I deal with them with a scope, and instead of tsconfig to install from #myOrg/tsconfig?
In your app's package.json, try these
"tsconfig": "*",
"eslint-config-custom": "*",
In pnpm, packages are installed by workspaces:*, but in other package managers you can do it by only *. We are using yarn, so * would be work.
Take a look at Offical Example.
If I understand it correctly, answer for the additional question is posted in github
discussions.
In package.json's name field, include your organization scope.
(#myOrg/package-name)
But don't change your folder's structure or it's name.
Related
I have a yarn/lerna monorepo with multiple packages that depend on each other. If I add packageA as a dependency to packageB and execute yarn install I see that node_modules/packageA is actually a symlink to packages/packageA instead of the published version of that package.
This creates problems on CI if packageB is build before packageA - the build fails because node_modules/packageA just points to the bare sources, without the build products (because packageA has not yet been built).
How can I force yarn to always download the published version of packageA?
yarn --version: 1.22.10
sidenote: If I wanted to use a local version of packageA instead, I would use yarn link or a local path instead of a version in package.json. Why is yarn defaulting to this behaviour?
One options is: "focussed workspaces" - see the guide here.
In my case, I added a file packages/packageB/.yarnrc that specifies to always use the --focus argument for yarn install:
--install.focus true
This will make sure that packageB has a copy of the published packageA in it's own node_modules folder.
However: This only works for one package at a time.
You can just build packages in order of dependencies. So in your case it'd be something like this in your CI (assuming there is a script entry called "build" in package.json of the packages):
yarn workspace packageA run build
yarn workspace packageB run build
This way you control the order of builds,they complete successfully, and you don't have to force using published package.
I'm building a site with yarn and hosting it on Netlify. I want to integrate another repo as a package, but I'd rather not put that package on the npm registry because it's very limited use. I hosted the package publicly via GitHub here and added it to my package.json:
"dependencies": {
"#ourjapanlife/findadoc-localization": "^1.0.0",
.
.
.
}
I can build the site locally and everything runs fine. However, when I deploy to Netlify, I get the following error:
10:38:06 PM: [1/4] Resolving packages...
10:38:06 PM: error Couldn't find package "#ourjapanlife/findadoc-localization" on the "npm" registry.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
10:38:06 PM: Error during Yarn install
I've created a .yarnrc file as follows and added it to the root of my project:
#ourjapanlife:registry" "https://npm.pkg.github.com"
I've researched this a lot, but most of the advice relates to private GitHub repos. I'm fine with this package being public, but I don't want it centrally hosted because it's just some i18n files of little use to the wider community. This answer also looked promising, but switching from .npmrc to .yarnrc did not solve my issue.
A collaborator helped me resolve this by running:
yarn add https://github.com/ourjapanlife/findadoc-localization
And the resulting entry in package.json looks like this:
"dependencies": {
"#ourjapanlife/findadoc-localization": "https://github.com/ourjapanlife/findadoc-localization",
.
.
.
}
At this point I could delete the .npmrc / .yarnrc and remove the prenetlify step.
It builds successfully on Netlify and resolved to the latest package via yarn.lock.
It turns out in experimenting, I had switched between the npm and github registries and manually edited package.json. It's better to re-install via the command line.
There are more and more front-end projects, and each project has its own node_modules folder.
There are a lot of duplicate files in the modules folder.
How can we manage the dependency packages of all front-end projects in one folder like Maven in IDEA?
Demand：
When running and packaging different projects, WebStorm can refer to the dependent packages in a specified folder.
When run npm install, computer will check whether the public dependency package folder has the dependency version that the current project needs to use.
If so, you will not download the installation.
If not, you will download your own dependency to the public folder.
When multiple versions exist in the same dependent package, the project can automatically reference the correct version.
Maybe after reading my question, you know my actual needs better than I do. Thank you.
If you look in the package.json file in any front-end project with npm you will see all the dependencies in the current project and can manage the versions there. npm install installs the dependencies listed in that file.
Read more about package.json here: package.json
Using the yarn workspace
Yarn workspace features, and solves
multiple projects repeat node in large quantities_ Black hole problem of modules disk
when NPM install is executed for a project, all dependent packages will be placed in the node of the project in the current project_ Install it again under the modules folder
2.1 when installing a new dependency package, you should update the package.json of the subproject, and then execute the yarn install in the root directory to install it
Install the yarn tool first
npm i yarn -g
If there are projects project-a and project-b in the root folder, the directory structure is as follows:
root
project-a
project-b
create package.json in the root folder, with the following contents:
{
"private": true,
"workspaces": ["project-a", "project-b"]
}
ensure that the name attribute values in the package.json of project-a and project-b projects are:
Package.json in project-a:
{
...
"name": "project-a"
...
}
Package.json in project-b:
{
...
"name": "project-b"
...
}
use the command line tool to enter the root folder and execute the yarn install
3.1 after installation, you can enter the normal start-up project
tips:
4.1 all dependent packages will be installed at root/node_ Under modules folder
4.2 node of subproject_ The related link file will be generated under the modules folder, do not delete it
4.3 when installing a new dependency package, you should update the package.json of the subproject, and then execute the yarn install in the root directory to install it
Below is the description of the issue:-
Expected behaviour is to have a package-lock.json file generated for every package in packages folder.
Current Behaviour
My current project structure look like:-
packages/internal-package-1/package.json
packages/internal-package-2/package.json
packages/internal-package-3/package.json
lerna.json
package.json
package-lock.json
Right now as shown above there is only one package-lock.json file which is generated for . the entire project and it only contains the dependency which in top package.json file.
My expectation was that for every package.json file corresponding package-lock.json should be generated but that is not the case. Furthermore, the top package-lock.json file only contains the dependencies in the top package.json and not the all the dependencies which are declared in evey package.json file.
Now, if we try to consume for example internal-package-1 in a different project that as there is no lock file for this package , latest version of the dependencies gets downloaded which is not the expected behaviour.
Possible Solution
Possible solution or expectation is to have a lock file generated for every package.
lerna.json
{
"packages": [
"packages/*",
"packages/Foundation/src/SampleNestedModule"
],
"version": "0.0.0"
}
This issue is affecting us because as the lock file is not generated for every package and if i try to consume the internal-package-1 in a different project then locked dependency are not getting downloaded but the latest version of them gets downloaded.
We are hoisting the dependency hence we have modified our npm install script as below:-
"install": "lerna bootstrap --hoist" , this correctly hoists the dependency but does not generate the lock file for individual package.
Executable Version
lerna --version 3.17.0
npm --version 6.10.1
yarn --version Not using yarn
node --version 10.16.0
| OS | Version |
MACOS
| NAME | VERSION |
| macOS Catalina | 10.15.2 |
Below are some of the post regarding same which i have already looked into-
https://github.com/lerna/lerna/issues/1462
https://github.com/lerna/lerna/issues/2105
Thanks,
Vishesh.
I couldn't find a concrete solution to generate lock files for all packages. I mean there are ways but, everything is increasing the installing time to very high. Below are 2 ways to generate package-lock.json file for all packages:-
Directly use lerna bootstrap without --hoist flag ------- This does generate lock file but increases the install time way to high.
Use "lerna exec -- npm i" ------ This will generate the lock file but "install" times are way higher not a viable solution with 25 packages in my repository.
As above 2 solutions were taking way to much time hence i considered them as not a feasible solution for large repos hence, i came up with a third way or i would call it a workaround , this is also not the cleaneast solution but does the job with very slight increase in installation time.
Create a npm script in all your packages which would generate only package-lock file without installation which would be something like below:-
"genPackagelock": "npm i --package-lock-only"
In you root package.json file as part of postinstall call the above defined script for all the packages as below:-
"postinstall": "lerna run --parallel genPackagelock"
The above "postinstall" basically generates package-lock.json file for all the packages along with the internal dependencies.
I have a project that uses yarn workspaces. The structure of the project is:
package.json
packages
- project A
- project B
- project C
When I run yarn install, the packages are installed in the project root node_modules. Recently I added another project (D) and ran yarn install. With project D, some of it's dependencies where installed in projectD/node_modules so I have some dependencies in the root and some dependencies in projectD and it's causing errors when I run the project.
Is there anyway I can "force" yarn to install all dependencies in the root node_modules?
I've just had this problem myself. It sounds like you have a version mismatch between a dependency of projectD, and a dependency of your other projects. The error you mention may identify what the dependency is (as it will give a 'cannot resolve module' error I'm guessing), otherwise you may find what's installed in projectD's node_modules folder will identify it.
Once identified I'd go through your yarn.lock file and work out which package/s have a dependency on the mismatching version. You may then find that updating the package that has the older version fixes your issue, or you may decide it's better to the use the nohoist option of workspaces
See:
https://dev.to/michalbryxi/share-common-code-with-yarn-workspaces-5g29
https://yarnpkg.com/blog/2018/02/15/nohoist/