I am using yarn 1.22.10.
I am developing a project which uses a yarn-linked dependency named module-one which in turn yarn-links to a dependency named module-two.
Is yarn able to follow these yarn link chains?
According to yarn documentation ,
a package can be linked into another project.
So if module-one is a package which is developed using module-two and then module-one is further called into another project using yarn link, technically it should work provided module-one is a package containing its own package.json.
But I would like to suggest not to use yarn link in a chain like wise because during production if dependency module-two modifies/updates/returns error and these changes are not translated to module-one; then the project might suffer and will return with unexpected errors/exceptions which will be pain to track and rectify.
Therefore I would like to suggest that you must install the module-two as dependency in module-one and then yarn link module-one to your project.
Related
I have a go project where the common functionality is implemented , and there is an another go project for the API which uses common functionality from the first project. API project uses the common project , the imports are done from git hub.
I have added a new functionality to the common project and trying to access that new functionality in API project . I have pushed the code to my branch in git hub (new code not there in master branch of common project) . How can I import the new functionality to API project
you could import packages from specific branch like this
go get <path-to-repo>#<branch>
You're probably looking for go get -u github.com/yourcommonproject. From go help get:
The -u flag instructs get to update modules providing dependencies
of packages named on the command line to use newer minor or patch
releases when available.
The -x flag might also be useful in debugging:
The -x flag prints commands as they are executed. This is useful for
debugging version control commands when a module is downloaded directly
from a repository.
Useful relevant links:
https://golang.cafe/blog/how-to-upgrade-golang-dependencies.html
https://go.dev/doc/modules/managing-dependencies
I am using Yarn's Workspaces feature to manage a monorepo. Some of the individual workspaces have their own dependencies defined in their own package.json, however I also have some shared dependencies (some are for testing the whole repo, some are used by all the workspaces). How do I declare these the correct way?
If I try to add them to the root package.json, Yarn gives me a warning. But adding the same dependency to all n workspaces (there are a lot and it's liable to grow) seems tedious and hard to maintain when upgrading dependencies.
Is the right thing to do to add the shared dependency (say, typescript, or jest or serverless) to every single individual workspace?
Using Yarn 1/classic.
I found also Yarn Workspaces: How and where should I install my dependencies? but it's unanswered
Yarn workspaces shared dependencies talks about using peer dependencies but the user is experiencing trouble
After a half-day search and trying, I found multiple ways to manage shared dependencies
1. Sync dependency version with syncpack
https://github.com/JamieMason/syncpack/
Given the fact that yarn workspaces will share the dependencies if their versions are the same (see https://classic.yarnpkg.com/lang/en/docs/workspaces/), all we have to do is to keep the dependency versions in sync to make dependencies sharing, which is exactly what syncpack does.
I found this is the least harmful way to make sharing dependencies works, while other methods require some degree of twisting package.json.
2. Use peer dependencies
For each package, set sharing dependencies as peerDependencies with version “*”, and set root workspace set the real dependencies. For example:
# ./package.json
{
...
"workspaces": ["packages/*"],
"dependencies": [
"some-lib": "^1.0.0",
]
}
# ./packages/pkg-a/package.json
{
...
"peerDependencies": [
"some-lib": "*",
]
}
and yarn install at workspace root.
3. Share script (require yarn v2)
See https://yarnpkg.com/getting-started/qa#how-to-share-scripts-between-workspaces
Miscellaneous
yarn provides workspace cli to add/remove package, see https://classic.yarnpkg.com/lang/en/docs/cli/workspace/
yarn workspace awesome-package add react react-dom --dev
yarn workspace web-project remove some-package
I was looking at https://yarnpkg.com/lang/en/docs/cli/policies/ and it seems like a good idea to use it to allow my team to easily be on the same yarn version. However, yarn policies set 1.18 downloads the full yarn release into .yarn/releases (a 4.5mb js file) and sets a config entry in the repo's .yarnrc file.
It feels weird to check in this 4.5mb yarn executable, but if I don't, my colleagues are not going to be able to run yarn, because the entry in the .yarnrc won't exist on their system and it's not magically downloaded...
So, is it best practice to check the .yarn/releases folder into version control?
Yes your assumption is correct, you check yarnrc and the actual yarn JS file into source control.
I'm trying to understand how to work with Golang and forks. The situation is the following, I'm writing a library project which depends on library github.com/other/some_dependency, which isn't mine.
Because some_dependency is missing some methods that I need, I fork it to github.com/me/some_dependency. However, I can't just do go get github.com/me/some_dependency, the library references itself so it breaks.
In this article they give a possible solution:
go get github.com/other/some_dependency
cd $GOPATH/src/github.com/other/some_dependency
git remote add fork git#github.com:me/some_dependency
git rebase fork/master
Now, this is hacky at best. There is no way from the code of the library to know that the dependency is coming from a different repo. Anyone doing go get of my library wouldn't manage to make it work.
As dep is expected to be the official dependency manager. I've found how to fix the version:
dep ensure -add github.com/foo/bar#v1.0.0
But I cannot find how to set a different remote. Is is possible to do it?
As an example, in Node.js with npm it is dead simple:
npm install git+https://git#github.com/visionmedia/express.git
If you look at the help you will see this:
<import path>[:alt source URL][#<constraint>]
So to add github.com/foo/bar from location github.com/fork/bar you have to add it like this:
dep ensure -add github.com/foo/bar:github.com/fork/bar
The source location will be added as source attribute in the Gopkg.toml.
Gopkg docs for dependency rules constraint and override
I forked ELKI from https://github.com/elki-project because I want to keep up to date with the latest development status while making my own changes and additions to the source (which I will possibly provide via pull request if it's sensible).
I followed the instructions in the README.md to package it with mvn package but there was no .jar created in elki/target/ - when checking out the release0.7.1 branch, it worked and I could start the minigui with java -cp elki-0.7.1.jar de.lmu.ifi.dbs.elki.application.ELKILauncher.
Is there a recommended way to try out the latest changes on the master?
We are currently in the process of modularizing ELKI.
But mvn package does create .jar files in elki/target/ here:
elki/target/elki-0.7.2-SNAPSHOT.jar
elki/target/elki-0.7.2-SNAPSHOT-javadoc.jar
elki/target/elki-0.7.2-SNAPSHOT-sources.jar
elki/target/dependency/elki-core-dbids-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-core-dbids-int-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-core-util-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-docutil-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-logging-0.7.2-SNAPSHOT.jar
elki/target/dependency/hamcrest-core-1.3.jar
elki/target/dependency/javaparser-core-2.3.0.jar
elki/target/dependency/junit-4.12.jar
elki/target/dependency/trove4j-3.0.3.jar
The main jar, ./elki/target/elki-0.7.2-SNAPSHOT.jar is runnable, but will only include the command line interface because of modularization - the minigui is optional now.
If you want a all-in-one bundle (as distributed on the web site), you need to enable the Maven profile bundle in addition to the functionality you want to include (e.g. mvn -Psvg,svm,uncertain,bundle package).