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.
Related
i was having issues on how vendor take too much place. Since my host has a limit on number of files and folders (INODES). So i found a solution to use one Vendor for multiple project in laravel through the following link : Using one Vendor Folder for Multiple Projects in Laravel 5.2.
In the following lines I put the vendor in projectA, then link the others projects to it.
In projectA everything works well when i do php artisan migrate:fresh --seed
When i try the same thing to projectB for example, the above command works till it arrives where the seeders should be executed. There, some error occur due to the fact that the command is trying to launch a seeder of projectA in the projectB as shown in the following screenshot.
Seeder Error Screenshot
So i want to know if there's a way to make the seeder separately.
I tried to create a symlink on the composer.json file as it was done for the vendor folder, but it doesn't work.
I'm using Laravel 8
I thínk this is a terrible idea, except in the case that both projects share exact same codebase.
Composer use composer.json as you know. How does your B project composer file determines how to resolve PSR4 autoload entries in Laravel, If it is symlinked to A project? That is probably the reason why your seed command is trying to locate Classes in A project.
Composer is clever enough to cache downloaded packages and reuse them, but I think that every project has its own dependencies and state, which is maintained by composer.json in the first case and composer.lock on the state case.
What happen if you update composer in A but not in B, will B work?
And last, composer autoload file reference all satisfied dependencies in your project, and in this case that (unique) autoload file will be loaded in both projects but what happen if your required packages are not exactly the same? ie You have Laravel Debug Bar in one project but not in the other. The autoload generated file will reference that package that will not exist on your other project.
Is not this the way composer work? Am I wrong?
In Composer the Vendor Directory (vendor in the project tree by default) is per project.
You ask about how to use one vendor folder for different projects.
Now first of all, this is absolutely not what Composer expects nor how it works. See Manuel Glez answer. In short a terrible idea.
When it comes to Composer, the place to share the actual PHP code across projects is not in the vendor directory but in repositories.
And as long as the dependencies are compatible, you could make one project depend on another and use its vendor/<vendor>/<name> folders as repositories. The remarks in Manuel Glez answer are still the same, this need to be same compatible versions across the board.
But to give the example, see Composer Path Repository which has this layout:
...
├── apps
│ └── my-app
│ └── composer.json
├── packages
│ └── my-package
│ └── composer.json
...
{
"repositories": [
{
"type": "path",
"url": "../../packages/my-package"
}
]
}
It can be adopted for each ../../project/A/vendor/<pkg-vendor>/<pkg-name> in ../../project/B/composer.json so that the vendor folder in project/A can act as a path repository for project/B.
As dependencies composer.json files normally do not contain the version, the documented remarks about repositories.options.versions apply:
When the version cannot be inferred from the local VCS repository, or when you want to override the version, you can use the versions option when declaring the repository:
{
"repositories": [
{
"type": "path",
"url": "../../packages/my-package",
"options": {
"versions": {
"my/package": "4.2-dev"
}
}
}
]
}
To prevent the duplication of the files the default strategy for Composer is to symlink the package directories. Ensure it works, then you only have one symbolic link per dependency in project B.
Okay how cool is that? Well IMHO while you still give up much of what Composer can do for you for dependency management, this at least makes use of local Composer repositories which I'd recommend for sharing instead of completely symlinking the overall vendor folder. Each project still have its own vendor/composer setup and overall what is done is much more well defined and in line with Composer itself.
Whether this works or not depends on the individual case. Key point here is as these local repositories only provide a single version per each package, you can only have that one. So these versions must all be version compatible on API level.
The system where it runs needs to support (relative) symbolic links, this should be commonly available for the situation described.
You could then automate the production of the repositories configuration and adopt it to the file-system layout. You could even generate the repositories and update them in the global configuration file so that each project would automatically prefer those packages from local.
$ echo "$(composer config --global home)/config.json"
/home/user/.config/composer/config.json
(compare: COMPOSER_HOME/config.json (Composer docs))
Take care all projects and their dependencies have a portable path-profile and then I'd say this should be quite straight forward shell processing.
To obtain the actual versions of the dependencies installed check per each vendor folder inside vendor/composer/*installed* files.
$ (echo "PACKAGE VERSION"; find .. -type f -path '*/vendor/composer/installed.json' -exec jq -r '.packages[] | .name + " " + .version_normalized ' {} \; | sort -u | sort -k 1b,2V) | cols
PACKAGE VERSION
composer/ca-bundle 1.3.2.0
composer/composer 2.3.7.0
composer/metadata-minifier 1.0.0.0
composer/pcre 3.0.0.0
composer/semver 3.3.2.0
composer/spdx-licenses 1.5.7.0
composer/xdebug-handler 3.0.3.0
...
phar-io/manifest 1.0.1.0
phar-io/manifest 1.0.3.0
phar-io/manifest 2.0.1.0
phar-io/manifest 2.0.3.0
...
(very old installations don't have the packages keyword, you'll likely want to filter)
Finally you may want to have something to smoke-test the setup easily so that you can have guards against the dependency incompatibility problems when you take notice of them.
I'm on version 1.22.X
I have a workspace like this:
/application
/common-package
/project-a
/project-b
Project A and B has similar dependencies but on different versions, this causes a bunch of issues so I want to add Project B to the workspace but I don't want Project B to hoist any dependency in the Application workspace.
I just want Project B to be able to import things from Common-Package.
I have tried:
/application/package.json:
"nohoist": [
"**/application/project-b",
"**/application/project-b/**",
]
But this isn't working and still sends some dependencies to application/node_modules.
I've also tried:
/application/project-b/package.json:
"nohoist": ["**"]
But again some packages still get hoisted. Then VS Code complains it cannot find them
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/*"]
}
}
}
If I run :
pnpm install eslint
Then my node_modules directory ends up containing:
node_modules
.bin/
.pnpm/
#eslint/eslintrc
eslint
eslint-scope
eslint-utils
eslint-visitor-keys
.modules.yaml
I can't seem to find anything particularly special about eslint or its dependencies that would cause that, but maybe I'm not looking at the right place.
The only thing that makes sense is that pnpm is hoisting these dependencies at the top solely based on the fact that they are prefixed by the name of the package I actually installed. That really doesn't seem right though.
What am I missing here?
In case someone else hits that head-scratcher:
The answer is simply that the default value of public-hoist-pattern contains *eslint*, so all eslint-related modules are special-cased.
see: https://pnpm.io/npmrc#public-hoist-pattern
I am trying to migrate from rx5 to rx6 by following the guide here. Initially, I installed along with the rxjs-compat package and everything works fine. However, when I try to remove the rxjs-compat package, I am getting an exception Cannot find module 'rxjs-compat/Subscription'. I used the rxjs-5-to-6-migrate to perform the migration
I am using this statement for Subscription : import { Subscription } from "rxjs";
For reference this is my branch- https://github.com/akshita31/omnisharp-vscode/tree/rxjs_update and this is the corresponding pull request that lists all the changes - https://github.com/OmniSharp/omnisharp-vscode/pull/2830
I updated all the dependencies to the latest versions and used the rxjs-tslint-rules as follows
npm install rxjs-tslint-rules --save-dev
Then in my tslint.json add the rule "rxjs-no-compat" : true
Execute ./node_modules/.bin/tslint -c tslint.json -p tsconfig.json in the project folder. This will give all the set of invalid imports
Resolve the invalid imports and then try removing the rxjs-compat package.
I also cleaned my npm cache - npm cache clean --force
If there are no more errors, we can as well remove the above tslint dependency from the package.json
More details can be found in the issue.
Thanks #cartant for the help
Do you by any chance still have some imports that are still using rxjs-compat?
With the migration from rxjs 5 to 6, you need to be very careful about all the imports, since you don't want to import some module from wrong the wrong path. I believe rxjs-tslint can help you.