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.
Related
I am trying to use yarn to add koa to my project folder but the command does not seem to work for me.
When I run the command it gives me the following warnings:
warning package.json: No license field
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
warning No license field
It tells me to remove the package-lock.json file but I don't have one in my folder as I just created the folder through the mkdir command.
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.
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
I used the CLI to install React Native, Node and Python but was not aware if I needed to save it to a file first.
I ran the yarn command:
➜ ~yarn add <package>
I would get this warning message when running yarn check:
➜ ~ yarn check
warning package.json: No license field
warning No license field
warning "jest-haste-map#fsevents#node-pre-gyp#^0.12.0" could be deduped from "0.12.0" to "node-pre-gyp#0.12.0"
Questions:
1. Do I only ~ yarn add when I start a project?
2. Since I've installed python, node, and react-native without creating a project folder will I run into issues down the road?
3. Do I add the json file with the licenses manually when starting a project with yarn?
4. Am I hopeless? lol
I've tried uninstalling and reinstalling from yarn and updating yarn. Also, I've tried installing python and node from Homebrew to see if that changes anything.
Below is a log of the output from the CLI after running ~ yarn check
Last login: Sat Aug 24 02:21:38 on ttys001
➜ ~ yarn check
yarn check v1.17.3
warning package.json: No license field
warning No license field
warning "jest-haste-map#fsevents#node-pre-gyp#^0.12.0" could be deduped from "0.12.0" to "node-pre-gyp#0.12.0"
success Folder in sync.
✨ Done in 1.99s.
Solution I figured it out! So after poking around I realized that once I started a project I had a yarn.lock and package.json file one level up in the directory where the file was located. What I did was I deleted yarn.lock and package.json associated with the folder in the directory. After that was complete I then went into my project and installed the correct packages.
You're not hopeless. This project may be, you've bitten off waaaay more than you can chew yet.
To answer your main question:
yarn add and it's cousin npm install will install the thing you tell them to in the node_modules folder in the directory you run the command in. The reason it's yelling at you is because usually you'll want to save the thing you installed as a dependency of your project, and you can't do that without a package.json file. You should run npm init to set up the package.json file for your project, then running yarn add will actually save it to the dependencies list so that you have a reproducible. If you have a package.json file already, it sounds like you maybe created it by hand (since it's missing a license field?) rather than have npm set it up for you, which is a bad idea.
Two more things:
React Native is awesome! ...But, it's a tool for people who already have good familiarity with Javascript command line/tooling/ecosystem/coding/React to build mobile apps. It is a lousy choice for a first project if you're just getting started with programming. Building a webpage with React is a lot easier, but even that may be too much.
If you really want to build a React Native app and you just can't wait look at this to get started.
But seriously, learn Javascript then npm then yarn then React then React Native. In that order.
I have been using npm for a personal project and just recently stumbled across yarn. Would there be any harm or "intended side effects" to switching to yarn's package manager in the same project where I had been using npm?
Although a few commenters here say its ok to mix both yarn and npm on the same project, after using yarn and npm and then yarn again, this is what yarn has to say about it:
warning package-lock.json found. Your project contains lock files generated by tools
other than Yarn. It is advised not to mix package managers in order to avoid resolution
inconsistencies caused by unsynchronized lock files. To clear this warning, remove
package-lock.json.
Since to me it is not any harm to using both them into one project.
I use npm and yarn (50/50) in dev environment.
But on ci/di i use only yarn because it is faster, and i reduce build minutes thanks yarn.
Also they both create different .lock file names.
Nobody told about the lock files.
Imagine you use yarn on dev environment, and yarn on your build/production servers. When you install a package using yarn, and your project works on your computer, you probably would want to keep it working on a production environment (your server).
That being sad, you would commit you yarn.lock file, that "saves" the exact versions of each package you have, when the project ran on your computer.
On your buid/production server you should call yarn install, but asking to keep all the same versions with --frozen-lockfile parameter. Some even say "yarn install --frozen-lockfile should be the default behavior", and I agree.
Then... another dev jump in the project you are working and install a package using npm (other than yarn). That new package will not be included in your yarn.lock file, but, a new package-json.lock file would be created, telling the exact packages versions it is using.
When that commit arrives on your build/production server, it will crash, fail, because that new package doesn't exist on yarn.lock file. Someone would need to pull that changes, call a yarn to install the dependences and update the lock file with the new package dependences, and push it again to the repo.
A quick point about using the lock file or not. If you call a 'yarn install' on your build/production server some weeks after the last install on your machine, the server would have many other new versions than your last "stable" version. It already happened to me many times.
I published recently the package-locks-checks, which help ensure you have not just one lock file but also locked each package version on your project.
There will be a point that one or both will no longer work and your project will be stuck at only using the existing lock file. Meaning, the issue probably will involve installation fails if you opt to reinstall without a lock file. And that also means failure to create a new lock file, so you are stuck with the existing one that you are trying to get rid off in the first place. We are actually encountering this issue in one of our projects. Because it is so big, no one tries to fix the issue and just rely on the existing lock file.
So, even if we say it's a rare case that it won't cause harm. Mixing npm and yarn should be avoided.
Here https://classic.yarnpkg.com/en/docs/migrating-from-npm/ we may find a confirmation that Yarn's resolution algorithm is compatible with NPM resolution algorithm.
Inside a npm project (with package.json) if you run yarn it will read your node_modules folder (using the resolution algorithm) and create a yarn.lock file with your project's locked dependency tree.
Based on that I assume that they are compatible inside the same project.
Update 30/04/2021
My original reply refers to yarn 1 (classic), although I've just created a React app with create-react-app tool and it creates the project's repository with package.json + yarn.lock by default. Again, another demonstration that it's fine (even with the warning mentioned by Dave Pile).
At the end of the day this is a matter of putting both together to work and checking yourself...
Plus you get a warning from yarn as Dave Pile said because we have to push *-lock.json files changes you have to consider using npm version >= 7 to make sure whenever you install packages by npm it will update your yarn-lock.json file too.
Because whenever you install the packages either by npm or yarn depends on what you have chosen for updating a dependency in the package.json (Using tilde ( ~ ) which gives you bug fix releases and caret ( ^ ) gives you backward-compatible new functionality) it will update you.lock file and since you have to push it might happen that you have different version of lock files.