assume I have a yarn workspace that have a few packages included the same CLI package, but different versions.
e.g
packageA => cliTool#1.0.0
packageB => cliTool#2.0.0
packageC => cliTool#3.0.0
Then after install, for <project root>/node_module/.bin/cliTool , which version of the cli is it linked to?
Related
I'm trying to solve what I assume is a common problem with poetry but am unable to find the relevant documentation. My project includes multiple packages and uses pyproject.toml and poetry to manage dependencies with this structure
/pyproject.toml
/poetry.lock
/package1/pyproject.toml
/package1/poetry.lock
/package1/src/package1/...
/package1/pyproject.toml includes pypi dependencies in [tool.poetry.dependencies] and defines the buildable package as
packages = [
{ include = "package1", from = "./src" },
]
/pyproject.toml references package1 with
[tool.poetry.dependencies]
package1 = { path = "./package1", develop = true }
Finally, my Dockerfile installs the application with
WORKDIR /app/package1
RUN poetry install
WORKDIR /app
RUN poetry install
The problem is that Poetry installs each "project" (identified by the pyproject.toml file) in a separate virtual environment, and doesn't seem to support installing both in the same environment. When I execute the application it can find package1 but none of package1's dependencies.
How can I get everything installed in the same environment?
How am I supposed to handle this situation?
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.
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 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/
I want to be able to pip install a package that installs a dependency package from GitHub. I want the version of that dependency package it installs to be the latest code in the master branch of the repository (i.e. I am not referencing a release of the package) (and there is a different version of the package for Python 2 and for Python 3). When I attempt to do this, the dependency is ignored. How can I get the dependency to be picked up and installed?
In setup.py I have lines like the following:
dependency_links = [
"git+https://github.com/veox/python2-krakenex.git;python_version<'3.0'",
"git+https://github.com/veox/python3-krakenex.git;python_version>='3.0'",
],
When I run pip, I do it using commands of the following form:
sudo pip install package_name --upgrade --process-dependency-links
I don't think it's possible. dependency_links aren't versioned, they're simple a list of URLs for packages listed in install_requires; those packages could be versioned but not in your case — you're trying to provide 2 URLs for one package which would confuse pip.
Perhaps you could rename one of the packages and provide package names
in the URLs:
install_requires=[
'krakenex;python_version<3',
'krakenex3;python_version>=3',
],
dependency_links = [
"git+https://github.com/veox/python2-krakenex.git#egg=krakenex;python_version<'3.0'",
"git+https://github.com/veox/python3-krakenex.git#egg=krakenex3;python_version>='3.0'",
],