I am trying to use Yarn Workspaces for my app that I am splitting into multiple packages such that I can share code between the mobile and web version of the app. Let me explain what I am trying to do with an example.
Let's say I currently have a mobile app called awesome-app. I am refactoring it by taking out the shared code and creating three packages as follows:
awesome-web
awesome-mobile
awesome-shared
Let's say I want to add new functionality to awesome-mobile for which I have to install depA to awesome-mobile. How can I do that such that yarn only installs depA and updates the package.json for the awesome-mobile. I tried using command yarn package <package-name> add depA but it ended up installing all the dependencies again which I want to avoid.
Also, let's say I want to use awesome-shared in awesome-web. Is there a yarn command such that it installs and updates the package.json for awesome-web automatically. Currently, I do it by hand and then I do yarn install in the root folder which ends up installing all the dependencies again.
Related
Let's say a I have the following monorepo structure using Yarn workspaces:
node_modules
packages
admin-app // WEB APP FOR ADMIN DASHBOARD
user-app // PUBLIC WEB APP FOR REGULAR USERS
packages.json
Let's say both admin-app and user-app will need to install React as a dependency.
Here is what I'll do to add React on both workspaces:
yarn workspace admin-app add react
yarn workspace user-app add react
Currently, this results in both of my packages depending on "react": "^17.0.2".
Inside my root node_modules, I can see that there is only one react folder in it. And the version is, as expected, 17.0.2.
But what if at some point I update React on admin-app and maybe forget to update it on the user-app. How will yarn install those two different versions of React? For example: 17.0.5 and 17.0.2?
As a I writing this question I've decided to test it.
Here is what I did:
yarn workspace user-app add react // THIS WILL INSTALL THE LATEST 17.0.2
yarn workspace admin-app add react#17.0.1
This was the result:
node_modules
react v17.0.1
packages
admin-app
user-app
node_modules
react v17.0.2
Yarn chose to keep the older version 17.0.1 in the root node_modules folder, and it installed the 17.0.2 in the user-app/node_modules folder.
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.
When I try with
npm install vuetifyjs/vuetify#v1.5.2
I get "Cannot find package".
UPDATE:
There is a packages folder under which there is a vuetify directory.
I tried npm installing that folder. Everything appeared to go well until I started the dev server.
Now in the console log I see:
[Vuetify] Multiple instances of Vue detected
Seems to be related to https://github.com/vuetifyjs/vuetify/issues/4068 but I cannot tell what the solution is at this point.
I had the same issue to use my own version of Vuetify, waiting for my pull request being accepted.
Here what I did:
I build the vuetify project with my fix.
yarn
yarn build
Then I took the content of 'packages/vuetify' and put it in a new git repository. I remove the .gitignore to be able to commit built files (/es5, /lib, /lib-temp, /dist)
Finally I add this git repository to my project to replace my vuetify version:
npm install git+https://gitlab.com/GITLABUSERNAME/REPOSITORYNAME.git
Looking at the package.json file, the package doesn't have a name property, which it would need to have for you to be able to install it from GitHub.
So the short answer is that you can't install vuetify directly from GitHub via npm.
However, you can install it directly from npm:
npm install vuetify#1.5.2
You can't install vuetify directly from GitHub but you can edit code in 1 component node_modules/vuetify/lib/components/VSlider/VSlider.js Then, you install patch-package and execute path package vuetify Delete node modules and execute yarn to create new node modules Last, yarn serve, you see your code is work
https://www.npmjs.com/package/patch-package
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.
We have a project which have to be packaged as a zip so we can distribute it to our cliens. With the normal node_modules directory i have no problems. I just put the directory and the node.exe together in my project folder and can start our project on every other computer without installing node or running any npm command.
But now i have a dependecy on phantomjs which needs to be installed as a global package npm install -g phantomjs.
How do i pack modules like this into our project? I first thought of copying phantomjs into the local node_modules directory and set the path variable NODE_PATH to this directory. It doesn't find phantomjs.
Development and client platforms are both windows.
Well, generally it is fine to install global dependencies with the --save flag and call their bins like ./node_modules/phantomjs/bin/phantomjs /*now executes*/ (just as an illustrative example).
However, with with Phantom it's not that simple, since it's downloading binaries and/or even compiling. You would have three options:
ssh into target and just npm install -g phantomjs before or define it in a manifest e.g. Dockerfile just like that, if you are using containers.
Compile it from source as advised here.
If you are using the CLI, then just the --save approach.
So I hardly advise just making a Docker image out of it and ship it as tarball. You can't zip the platform dependent Phantom installation, unfortunately.
Also lots of dependencies like karma-runner-phantomjs look for the path of the global dependencies to resolve it for their use.