My team has a monorepo where we are using bolt to manage dependencies and linking. I was trying to get the dev environment up and running on my local Windows machine but had issues install/link acorn. What I did was clone the repo, then $ bolt to install dependencies. As you can see, it showed error linking dependencies and complained about acorn.ps1 not being a symlink. I've done some research but none of the solutions I found, such as including --non-bin-links or running as admin, worked for me. I'd appreciate if you could provide some insights on this.
Windows: 10;
Yarn: 1.13.0;
Bolt: 0.22.6 - tried 0.22.4 as well but did not work;
Ok I found the solution to this issue.
acorn is not a dependency for my project, but it is one for yarn itself, as I searched for it and it only appears in yarn.lock. Meaning there's definitely something weird with my current version of Yarn, 1.13.0. So I downgraded it to 1.12.3 and according to the official documentation, installed bolt as a local package instead of a global one. It solved this issue.
Related
I attempted to check the version of my go executable with go version on an Ubuntu machine, however I got the following error:
No version set for command go
Consider adding one of the following versions in your config file at
golang 1.16.8
golang 1.17.1
How do I resolve this? I have no prior experience with config file, I searched on google but I found nothing which could solve this issue.
That seems to be an error message from asdf-vm/asdf, a tool which manages multiple runtime versions with a single CLI tool, extendable via plugins.
You can see that error message in asdf-vm/asdf issue 838.
The config file should be in $HOME/.tool-versions
To resolve this, as in this example:
asdf plugin add go
asdf install go latest
In the next version of yarn ("berry") the manual states that one should just commit the directory created called .yarn, but if you use the multi-version setup for yarn, this directory contains the file releases/yarn-berry.js which seems to be the entire berry version of yarn, taking up more than 2MB of disk.
This just seems really wrong - why should I commit a package manager to git, just to get it to work?
The Yarn developers explain the rationale for this in the Installation docs, in the section called "About global installs":
Using a single package manager across your system has always been a problem. To be stable, installs need to be run with the same package manager version across environments, otherwise there's a risk we introduce accidental breaking changes between versions - after all, that's why the concept of lockfile was introduced in the first place! And with Yarn being in a sense your very first project dependency, it should make sense to "lock it" as well.
Once Yarn is tracked and "locked" as a per-project dependency, it ends up getting committed to Git if you follow Yarn 2's zero-install strategy, the rationale for which is explained here.
I'm a newcomer to Yarn, but I spent years working devops, helping developers figure out why their code would sometimes build correctly on half of the team's laptops but not on the other half, or would suddenly start failing to build in CI while continuing to work elsewhere. Trying to keep the version of npm consistent across every computer and codebase in the company was essentially impossible, given that Node is constantly being upgraded, but locking each project to its own specific version of Yarn -- which, by being committed to Git, is guaranteed to be available in every checkout of that project -- solves this problem.
I have written a small tool for those people who don't want to commit Yarn 2+ binary into their git repos, while still benefiting from sticking Yarn version per project. If you already have Yarn 2+ configured in your project just don't want to commit it, you can run:
yarn dlx pinyarn
This command will generate .pinyarn.js (4KB) which you should commit, instead. .pinyarn.js will contain URLs inside to download Yarn 2+ and its plugins from the official Yarn Berry GitHub repo. .pinyarn.js will download binary and plugins from these URLs if they are not downloaded yet.
You can also specify which version of Yarn 2+ you want via:
yarn dlx pinyarn 3 - the latest released Yarn 3 version, or
yarn dlx pinyarn 2.2.2 - version 2.2.2, or
yarn dlx master - version from latest sources, or
yarn dlx 1638 - version from Pull Request 1638
The pinyarn tool repo on GitHub:
https://github.com/sysgears/pinyarn
The official documentation mentions what's should be ignored and what should be committed. It can solve this problem I think.
https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored
The new docs states using node's newest corepack feature (to date).
This means that when using appropriate node you only need to place a valid packageManager field value in package.json and run corepack enable, e.g.
{
"name": "foo",
"packageManager": "yarn#3.2.0",
"scripts": {
...
}
}
For a few days I have been getting these messages:
*> yarn run v1.21.1 $ react-scripts start
There might be a problem with the project dependency tree. It is
likely not a bug in Create React App, but something you need to fix
locally.
The react-scripts package provided by Create React App requires a
dependency:
"eslint": "^6.6.0"
Don't try to install it manually: your package manager does it
automatically. However, a different version of eslint was detected
higher up in the tree:
/home/sol/Repository/node_modules/eslint (version: 6.3.0)
Manually installing incompatible versions is known to cause
hard-to-debug issues.
If you would prefer to ignore this check, add
SKIP_PREFLIGHT_CHECK=true to an .env file in your project. That will
permanently disable this message but you might encounter other issues.
To fix the dependency tree, try following the steps below in the exact
order:
Delete package-lock.json (not package.json!) and/or yarn.lock in your project folder.
Delete node_modules in your project folder.
Remove "eslint" from dependencies and/or devDependencies in the package.json file in your project folder.
Run npm install or yarn, depending on the package manager you use.
In most cases, this should be enough to fix the problem. If this has
not helped, there are a few other things you can try:
If you used npm, install yarn (http://yarnpkg.com/) and repeat the above steps with it instead.
This may help because npm has known issues with package hoisting which may get resolved in future versions.
Check if /home/sol/Repository/node_modules/eslint is outside your project directory.
For example, you might have accidentally installed something in your home folder.
Try running npm ls eslint in your project folder.
This will tell you which other package (apart from the expected react-scripts) installed eslint.
If nothing else helps, add SKIP_PREFLIGHT_CHECK=true to an .env file
in your project. That would permanently disable this preflight check
in case you want to proceed anyway.
P.S. We know this message is long but please read the steps above :-)
We hope you find them helpful!
error Command failed with exit code 1. info Visit
https://yarnpkg.com/en/docs/cli/run for documentation about this
command.*
I tried everything above, but nothing helps and I'm really upset about this situation because I can't get my code to work.
Can someone help me with easy instructions because I don't have time anymore to try and find a solution to the problem.
I could not solve the problem:
There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.
The react-scripts package provided by Create React App requires a dependency:
"eslint": "^6.6.0"
Don't try to install it manually: your package manager does it automatically.
However, a different version of eslint was detected higher up in the tree:
/Users/elvestrindade/node_modules/eslint (version: 6.2.2)
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.
Brief context: I was using an older version of node but decided to upgrade node so I downloaded the .msi and installed it. Installation went normally, however npm stopped working and I get this error
Here's a screenshot of PATH
How do I solve this problem?
I have also encountered this problem exactly likes yours on my server(CentOS 6.8), and I solved it finally.
Though the OS are different, but hope it's helpful to you.
Here is my solution:
Delete the directory node_modules, and uninstall node and npm, then reinstall them.
Then you may fix the issue.