This is my project set up
proj:
package.json - workspaces["app/frontend", "app/backend"]
app
frontend - package.json
backend - package.json
say I cd to proj
I want to do yarn workspace app/frontend add uuid -dev (add a pkg to one of the workspace)
err is Unknown workspace "app/frontend", wonder what is the correct syntax?
yarn workspace frontend add uuid --save-dev
When you define your workspaces in the package.json you should use relative path to the workspace:
"workspaces": [
"app/frontent",
"app/backend"
]
However, when you refer to your workspace in yarn workspace ... command you should use the package name of this workspace (including namespace).
For example, if your frontend/package.json defines
{
name: "#myproj/frontend".
...
}
you will use
yarn workspace #myproj/frontent add uuid --save-dev
Related
I have a monorepo with this dependency tree:
/root
package.json
/packages
/api <--- requires node v16.x because of a critical dependency
package.json
/ui <--- requires node v14.x because Vercel does not yet support v16.x
package.json
/shared <--- shared code between both /ui and /api
package.json
I'm unable to deploy the /ui package on Vercel because it complains of about the dependency under /api that requires v16.
Is there a way to configure yarn workspaces such the offending dependency can be ignored when building /ui, or is my only option to eject from yarn workspaces and find some other way to share the /shared code?
Another way of asking the question:
I have repo A which must run on node 16, and repo B which must run on node 14. How can I share code between the two repos? Yarn workspaces isn't working for me because it forces all packages to conform to a single node version.
I ended up ejecting /ui from yarn workspaces, and continuing to share code by just importing the files from outside of the package's root directory.
I had a lot of file includes that utilized the following convention because of yarn workspaces:
import { someFunc } from '#project/shared/someFile'
Quite elegantly, I was able to continue sharing code without having to change that syntax at all - by simply updating jsconfig.json to simulate yarn workspaces:
{
"compilerOptions": {
"module": "commonjs",
"baseUrl": ".",
"paths": {
"#project/shared/*": ["../shared/*"]
}
}
}
I have a project with yarn (v1) workspaces.
project/
packages/
pkgA/
subPkgA1/
pkgB/
package.json has this:
"workspaces": {
"packages": [
"packages/pkgA",
"packages/pkgA/subPkgA1",
"packages/pkgB"]}
note that there's a nested workspace in there.
Top-level has jest#27.4.7 in its package.json.
pkgA has jest#24.9.0 because one of its dependencies requires that version; its package.json has no entry for jest.
pkgA/subPkgA1 has jest#27.4.7 in its package.json, BUT it actually gets 24.9.0 installed in its node_modules/.bin/jest, presumably because its parent workspace has that.
My main question is how to get jest#27.4.7 in the nested package subPkgA1? I tried adding an entry in pkgA's package.json, but that didn't help.
BTW, I know nested workspaces aren't fully supported until Yarn v2, but I can't upgrade right now, and I can't easily move my subpackage out of its parent, so any hacky solution would be better than nothing.
Just upgraded from Yarn 1 to Yarn 3.
In my package.json of my "Project 1" I have a dependencies to my published package
dependencies: {
...
"#my-package/name": "3.4"
...
}
With Yarn 1 not altering package.json when linking "Project 1" to "#my-package/name" for local development, that worked fine.
Linking my local version of the package with Yarn 2/3, it now added
"resolutions": {
"#my-package/name": "portal:../name"
}
This breaks the build process during deployment on staging/production environments. That link is only meant for local development, while on other environments it should be ignored and (only) the published package above should be used.
Any idea if / how this is now possible?
Here is the ticket on that issue/change https://github.com/yarnpkg/berry/issues/90
In yarn 3, I tried:
yarn link ~/local/package/path
It added:
"resolutions": {
"#namespace/package": "portal:/home/src/repo/local/package/path"
}
was working for me to deploy in staging env for testing. (Note: We have different setup for prod)
When trying to import a repo into my lerna monorepo it keeps failing with:
lerna ERR! EDESTDIR --dest does not match with the package directories: packages
I'm using the default lerna.json config.
{
"packages": [
"packages/*",
],
"version": "0.0.0"
}
The import command I'm using is:
npx lerna import --flatten /Users/home/Desktop/Lerna_Tests/docs-repo --dest=docs
I also tried:
npx lerna import --flatten /Users/home/Desktop/Lerna_Tests/docs-repo --dest=packages/docs
However, both fail with the same error.
I want the repo to go to the packages/docs directory.
Summary
I added a directory glob entry to my lerna.json packages array and added quotes to my import command to fix it.
Explanation:
I realized that when setting up the lerna.json I was using the default lerna.json config but needed to add an entry to the packages array like this:
{
"packages": [
"packages/*",
"packages/docs/*" <<<<<<<<< I added this line.
],
"version": "0.0.0"
}
NOTE: the /* is important after the directory.
Once I added this, the following command imported my repository without a problem:
npx lerna import --flatten /Users/home/Desktop/Lerna_Tests/docs-repo --dest="packages/docs"
Note: I tried without the quotes around the destination directory and it didn't work for some reason. The docs for Lerna give an example without using quotes so I assume that it must be okay in some circumstances just not in mine.
This SO question and answer helped my fix my error. However, it was a different solution and a different problem so I thought I'd post my question answer for those whose issue relates closer to the above situation.
Calling yarn commands inside a package that references a local lerna package fails with
- packages
- package1
- package2
say package2 references package1
dependencies: [
"#my-scope/package1": "^1.0.0"]
When I run any yarn command in package2 e.g. yarn add, or yarn list I get an error:
An unexpected error occurred: "https://registry.yarnpkg.com/#myscope%2package1: Not found".
I have run lerna bootstrap at the top level with
"npmClient": "yarn"
which successfully builds all my packages and the node_modules of package2 contains package1, however the yarn.lock file does not have any of the local packages
What might I be doing wrong?
Your dependence version should match origin's version, otherwise, yarn will lookup by internet instead local package
Say
packages1's package.json:
{
"name": "#my-scope/package1",
"version": "0.0.1"
}
packages2's package.json:
{
"name": "#my-scope/package2",
"dependencies": {
"#my-scope/package1": "^1.0.0"
}
}
yarn can's find that version match ^1.0.0, so it just try fetch from yarnpkg.com