What is Reddit's opinion of
Yarn?
From 3.5 billion Reddit comments
100 reviews of this app found across Reddit:
Algolia would probably allow you to use their search platform, similar to what they did for the yarn website. It's super fast, probably better than what you could reasonably build as a side project.
There's no yarn upgrade in Yarn 2, its replacement is yarn up. The author went out of their way to break it with Yarn 1.
For anyone looking for a better upgrade experience in Yarn 2 try <code>yarn upgrade-interactive</code> or <code>yarn semver up</code> to blindly upgrade within semver exactly like yarn upgrade. The latter is a community plugin.
Thumbs up: Ask yarn why a package is installed
Thumbs down: No replacement for npm search
Edit: The overall benefits look pretty amazing and I'm definitely going to be giving yarn a spin
Note that install.audit is actually --install.audit. It's a special syntax that basically means "whenever the install command is called, add the --audit flag". You can use that for any flag, and the install part isn't required - --audit true should also work (it will be ignored on commands that don't support it).
Overall the best yarnrc flag imo is yarn-path, that you can use to enforce a Yarn version across your team. You might actually use it without being aware if you use the <code>yarn policies set-version</code> command, which uses it under the hood.
As for check-files, it's not a super useful option - it will just cause Yarn to trigger a reinstall if it detects that a file got removed somewhere inside the node_modules (otherwise it will bailout).
Would you be surprised that yarn’s advice is literally to disable your antivirus to speed up the downloading and running of random code from the internet?!
https://yarnpkg.com/en/docs/install#windows-tab
> Please whitelist your project folder and the Yarn cache directory (%LocalAppData%\Yarn) in your antivirus software, otherwise installing packages will be significantly slower as every single file will be scanned as it’s written to disk.
But it’s faster than NPM so that’s the most important thing, right?
I'd suggest ditching bower instead of ditching NPM. Bower is pretty much dead and NPM is great for both front-end and back-end JS these days.
Also use Yarn as a replacement for the NPM command line tool.
Also, Webpack and Rollup have taken a lot of the momentum away from Gulp. It can be a pain to switch if you've got a good Gulp workflow, but at this point I think Gulp has an expiration date.
On the bright side, I think our work already had a impact on the ecosystem. Since the 2.0 release, a lot of incorrect dependencies have been identified, and the overwhelming majority of their maintainers have been open to address them. Nowadays there aren't that many of them left.
We also now provide the <code>packageExtensions</code> setting which lets you add the missing dependencies yourself (so that you don't have to be blocked on upstream), and we even ship a few of those extensions by default.
All in all, inside one of my side project which uses Next/Babel/Apollo/Redux/LotsOfThings, I only need five such extensions (which are fairly easy to write, since Yarn tells you what package tries to require which dependency - so it's mostly a matter of just following the instruction you get in the error message).
https://yarnpkg.com/blog/2017/05/31/determinism/
For the Yarn vs NPM debate, I point to this. Seems like NPM wins.
> npm 5 has stronger guarantees across versions and has a stronger deterministic lockfile, but Yarn only has those guarantees when you’re on the same version in favor of a lighter lockfile that is better for review. It’s possible that there’s a lockfile solution that has the best of both worlds, but for now this is current state of the ecosystem and possible convergence could happen in the future.
Here's a StackOverflow answer on the topic
> As for comparison with npm shrinkwrap, the documentation explains it very clearly:
> > It’s similar to npm’s npm-shrinkwrap.json, however it’s not lossy and it creates reproducible results.
> ...
> The lossy behaviour of npm shrinkwrap is due to the non-deterministic algorithms used by npm itself; as stated in the comments of another answer, npm shrinkwrap > npm install > npm shrinkwrap is not guaranteed to produce the same output as just shrinkwrapping once, whereas Yarn explicitly uses "an install algorithm that is deterministic and reliable".
npm is certainly closing the gap here, as this post states, but there's still some advantage to yarn.
Plus, the fact that yarn is just faster than npm (due to its local caching) doesn't hurt either.
If you're talking about package version mismatches then Yarn might be worth checking out. It's a drop-in replacement for npm that creates a lockfile (specifies exactly what version of each package to install) and has the positive side-effect of faster installs (yarn install vs npm install).
I've been using it for several months now and I don't have any complaints.
I got an error when I ran yarn, even though I have it correctly installed.
​
C:\Users\melol\Desktop\shapez.io-1.3.0\electron>yarnyarn install v1.22.5[1/4] Resolving packages...[2/4] Fetching packages...error Command failed.Exit code: 128Command: gitArguments: ls-remote --tags --heads ssh://[email protected]/tobspr/shapez.io-private-artifacts.gitDirectory: C:\Users\melol\Desktop\shapez.io-1.3.0\electronOutput:Host key verification failed.fatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists.[3/4] Linking dependencies...error An unexpected error occurred: "ENOENT: no such file or directory, open 'C:\\Users\\melol\\AppData\\Local\\Yarn\\Cache\\v6\\npm-shapez-io-private-artifacts-0.1.0-63adf7e0ea4b90c2a29053ce1f0ec9d573b3ac0a\\node_modules\\shapez.io-private-artifacts\\.yarn-metadata.json'".info If you think this is a bug, please open a bug report with the information provided in "C:\\Users\\melol\\Desktop\\shapez.io-1.3.0\\electron\\yarn-error.log".info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Did you use the windows installer to install node or are you using nodeenv? I personally use nodeenv when on a windows environment.
Did you follow installation and migration guide?
We stopped distributing Yarn as a global binary so that projects can upgrade on a case by case basis. It doesn't help the adoption, but it was the right thing to do.
This workflow also makes it much easier to ensure that all your developers share the exact same Yarn version without having to install any specific version of Yarn.
You create a package.json file by initialising an npm app. This can be done with a package manager such as npm or yarn, or you can even just manually create and write the file with any text editor.
To use a package.json file, you edit it with a text editor such as Vim, Sublime, VS Code, etc.
The file is read by npm (or yarn etc) when performing instructions. The full documentation can be found on npm's website.
or if you use npm:
But in general - yes, your packages are specific to a given project. Here's a bit of discussion on it:
You should add them globally to your system if and only if they have a command-line interface you will be using (eg. create-react-app which creates a project template). If you need to move your code to a different place then you have a yarn.lock (if you use yarn) file which specifies versions of each library to install on a target machine for a specific project. This way you avoid incompatibilities caused by packages constantly updating/changing.
Go to and set up devdocs.io before you go. This will give you offline access to a lot of popular web docs if you enable and install them when you are online.
Look into using npm or yarn offline (basically by caching packages that you will use before hand).
Use (Yarn)[https://yarnpkg.com/en/] (even Bower recommends using it if you read the log lines) for package management. It is a wrapper around NPM that does a lot of nice things under the hood.
Grunt is basically a build tool that automates certain tasks (it's know as a "task runner"). Gulp is another task runner. The difference is in how you tell them what to do.
You'll also hear about Webpack. Webpack is module bundler. Modern JS is written in modules. Webpack takes them, combines them, and gives you a few JS files to use in your application (this is grossly over simplifying what Webpack can do, it's super powerful). Rollup is another bundler. Rollup is often used for the modules themselves or simple apps because it can produce super tiny bundles. Webpack is often used for larger more complex applications.
I'm not sure what else you're finding confusing but let us know and we can try to help clarify.
bower is officially deprecated...the new sauce is either using new-oldschool npm or the hipster kids are all over yarn (which, hey you can install with npm! npm install -g yarn)
As others have already mentioned - you probably will have to go with monorepo.
If your use case is that simple (only one shared package) I would recommend using Yarn workspaces. Yarn supports that natively and let’s you manage your monorepo pretty easily. But that implies you using yarn as your package manager for the project, you probably won’t be able to achieve that with npm.
Another solution that I heard of, but didn’t try myself, is just creating a shared folder and symlink it in your other packages. This solution probably doesn’t need any extra tool, you don’t even have to initialize your shared folder as an npm package. Don’t know how symlinks work on Windows, but they should work pretty well on Linux (if you push your code on GitHub, it will recognize those symlinks).
To conclude, if your use case is simple and you don’t have a lot of shared packages, I would go with yarn workspaces. If it’s a bit more complex, then I would pick some more advanced tool for managing monorepo, like lerna.
- Use Yarn 2
- Set the
mainproperty frompackage.jsonto your real source files (let's saysrc/main.ts) - Set the <code>publishConfig.main</code> property to the transpiled sources (
dist/main.js) - If your sources are for Node, use either
ts-nodeorbabel/registerto add support for TS files.
This will let you use your real sources in development without need to rebuild them, while still letting the published artifacts reference whatever static build you will provide your users.
Don't listen to /u/enf0rcer.
You must have a running version of yarn, so go and get it here.
Then it's a matter of doing the commands given in the README file, i.e. the quick start is yarn gulp run
Yeoman.io is one idea, as others have mentioned. You could also take a look at yarn create. I think you basically just have to have an npm package called create-<whatever your starter kit name is> and running yarn create my-starter-kit my-app will bootstrap a new project from that template. Examples are create-next-app, create-react-native-app, and of course create-react-app.
Nice! You might also want to check out [concurrently](https://yarnpkg.com/en/package/concurrently). You can stick the "concurrently" command in your package.json and run it the same way, and it is cross-platform too.
> Imagine your node program has a dependency on a library that hasn't been published to npm.
There are a lot of built-in solutions in NPM/Yarn:
- Add the dependency as a link to GitHub - NPM has a built-in support for GitHub URLs
- Add the dependency as a Git URL - both GitHub and self-hosted repositories work, including private repositories.
- Put the dependency anywhere on the internet as tarball, and add that as a reference. NPM handles that too.
- Vendor the dependency and refer to it using a relative path or with Yarn workspaces. You can also vendor tarballs, if you need to do so for whatever reason.
- If all else fails, you can write custom dependency resolution logic as a separate script, and add it as a preinstall hook.
These work for both your program and your dependencies, and their dependencies, and so on.
You can't require global modules. See https://stackoverflow.com/questions/15636367/nodejs-require-a-global-module-package for two different options.
^^^^^^also ^^^^^^use ^^^^^^yarn ^^^^^^for ^^^^^^offline ^^^^^^mirror ^^^^^^https://yarnpkg.com/blog/2016/11/24/offline-mirror/
I also prefer Linux. There are a couple of things I do to keep up-to-date with Javascript development:
- use <code>nvm</code> to keep up-to-date with current Node releases, or to get the appropriate Node version for a project
- follow Yarn's installation instructions for Linux (if you use
yarn) which will get you set up with a repository to track Yarn releases automatically
Beyond those dependencies most tools that I use can be installed with yarn global add or npm --global install. From time to time I have to translate a brew install instruction to an apt-get for the corresponding package.
I use Debian Testing, which has more up-to-date software than Ubuntu does. But I don't think that makes much of a difference for Javascript development when you have specialized sources for Node and Yarn anyway.
Maybe you could tell us more about the particular struggles that you encounter?
I don't know if it would solve it, but I finally switched to yarn yesterday and my only regret is not doing it sooner.
For anyone reading: Google how to install yarn for your platform (on a typical dev's Mac it would be "brew install yarn"). Go to your folder, and type... wait for it...
yarn
You're done. Now just type yarn instead of npm. It'll most likely be a lot faster and more reliable (and anyone sharing the codebase can keep using npm). I had no idea it was that easy I assumed I was going to have to learn some whole new package manager.
They lock in the versions of each dependency and make the package management deterministic. The reason you would want this is so you get a consistent setup on all computers. When you commit the lock-files to the repo, you are ensured to have the same output regardless of which computer you build/compile on.
There's more info on this subject here: https://yarnpkg.com/blog/2016/11/24/lockfiles-for-all/
According to the official docs, yarn install is the equivalent to npm install.
https://yarnpkg.com/lang/en/docs/migrating-from-npm/
It's good to know that yarn works just as well, but that isn't the reason that yarn didn't work for me.
Bower is dead huh? And what is that based on? People who have not been developing for a long time love to jump on new technology (well all devs love this) without considering that everything has a shelf life even the new thing you're all amped up on.
Like there's things already challening NPM like yarn https://yarnpkg.com/en/
These things come and go. Bower isn't dead. It's being used on 1000s and 1000s of projects daily. WebPack may have figured out how to do a few things better but it's really very surely not 'dead'. Death in computer science is a far, far more drawn out process than adoption.
I looked at npm and webpack. Something seems funny about it. My guess is in 3 years I won't be using it at all and THAT'S the thing we should be switching to.
That update/upgrade thing will never settle in my brain. In every package manager it means something different. I always confuse it in brew, npm and apt-get.
Also in their documentation I failed to find an equivalent of npm start. Anyone knows how to do it with yarn?
I ran into the same issue as well, idk if this is the right way to handle the issue. But when I checked the yarn docs for the error code YN0018, it says that you can set a default checksum behavior. So in my .yarnrc.yml I added this
checkumBehavior: update
And things seem to work, hopefully that helps. If someone can summarize what's going on here, I would appreciate it.
Depends on your package manager then. pnpm and yarn both support the resolutions property in the package.json so you can do
"resolutions": { "colors": "1.4.0" }
npm version 8 supports overrides (similar to resolutions), otherwise you can use a package like <code>npm-force-resolutions</code>
First point, an NPM package being removed doesn't have to stop you build or deploy failing. In fact, you shouldn't be pulling anything from the net at that point anyway. Yarn and PNPM have mechanisms to solve that (eg https://yarnpkg.com/features/zero-installs). Alternatively you can just check node_modules into your repo (slightly controversial but it's what Google does...).
Secondly Marak wasn't exactly wrong to do what he did. For billion dollar corporations to use open source work without giving back is very sucky. Technically they can, but morally they shouldn't. People will continue to do this sort of thing while they refuse to pay major maintainers.
And lastly, the idea that Node isn't serious for backend dev work because of NPM... That's funny. Literally every language that enables devs to pull code from a remote location at build time has this issue. Even if the registry doesn't let maintainers remove things, the registry could be offline for a million other reasons. You have to make your pipeline robust if you need to deploy at any time.
That's actually exactly what Yarn v2/3 does with its "zero-install" approach - it caches the .tgz files in the repo, and you commit them:
https://yarnpkg.com/features/zero-installs/
(I also used to do this with a tool for npm called shrinkpack a while back.)
Hi All
After passing all the required details for contracts bootstrapping, showing error:
Bootstrapping contracts...
Encountered error:
warning ..\..\package.json: No license field
UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "undefined".
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Yarn 2+ uses this so you can write rules about your monorepo dependencies, e.g. mandate that every package in your repo depends on the same version of a library, disallow certain dependencies, etc.
issue is fixed
​
fixed for me. you should install peer dependencies first.
https://yarnpkg.com/package/react-native-dynamic-vector-icons
https://yarnpkg.com/package/@freakycoder/react-native-helpers -- must
then add bouncy checkbox yarn add .....
​
But why it does not install peer dependencies automatically.
I got this error when trying to build the game:
[17:08:11] Error: spawn ffmpeg ENOENT
at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)
at onErrorNT (node:internal/child_process:477:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21)
[17:08:11] 'sounds.sfx' errored after 60 ms
[17:08:11] 'sounds.buildall' errored after 60 ms
[17:08:11] 'sounds.dev' errored after 61 ms
[17:08:11] 'build.dev' errored after 3.47 s
[17:08:11] 'main.serveDev' errored after 3.47 s
[17:08:11] 'default' errored after 3.47 s
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this comm
and.
> NPM needs to have more checks for when packages that haven't been updated in literal years get spammed with several quick updates all in sequence. Hell, there should be a check for just bumping the version once on a library like this given how long it's been sat.
Maybe it'd be possible to have some kind of moratorium on package updates, like if a package is updated yarn add and npm i will not actually install it for another 6 hours. Developers could skip the waiting period with a special publish command that requires their account to have 2FA enabled.
Besides that, one of the really serious problems with the npm ecosystem is the existence of a large number of micro packages that should be migrated away from. We should really start some kind of project to identify these and opt into receiving errors when they're about to be installed. This will help identify where they need to be removed from, and the resulting effort will significantly reduce the attack surface.
Similarly, I'd be interested in seeing warnings generated during install if any of the packages I'm interacting with are under an account without 2FA.
I'd also feel a bit more secure if npm/yarn had some way to scan all your project dirs to see if any known compromised packages are installed anywhere. Even if most of them work through an install hook, you could have obtained a copy from other methods too (especially with zero-installs becoming a thing). The audit command doesn't work adequately for this purpose.
> how do I leave?
press ctrl-C (aka C-c), that sends an interrupt. Sometimes you need crtl-D though, as some programs like REPLs will trap the interrupt from C-c.
Another way to install (from yarn's site) would be this:
curl -o- -L https://yarnpkg.com/install.sh | bash
For Homebrew though, some tips from here might help if you want to try getting that install to work instead. https://github.com/Homebrew/legacy-homebrew/issues/15077
My situation:
- 1 Monorepo with Lerna + Yarn v2 workspaces for shared packages.
- 1 repo per app that use packages from monorepo.
Looked at Rush and NX for a bit, but I don't really see the benefit of Rush over my current situation (Rush+Yarn "should just work" but I don't feel like trying, otherwise you are stuck with NPM 4.5 according to their docs??). NX seems too opinionated about things.
Installing node_modules is really fast, just let Yarn do its thing. Yarn docs aren't great and it's hard to find info on v2, most guides are written for v1. Lerna breaks when using Yarn's workspace:* protocol.
I'm still looking for a way to manage shared configuration/devDependencies/scripts between packages in the monorepo. Currently need to copy all devDependencies to all packages, that's no fun. Yarn docs talk about using a colon in npm scripts that can be run in any workspace here, but I still run into dependency issues.
The problem with not having a lockfile is npm installs without one is time- and order-dependent. Time-dependent in the sense that the running npm i against the exact same package.json file at two different times can create two different node_modules tree. Order-dependent in the sense that npm i pkg-a && npm i pkg-b and npm i pkg-b && npm i pkg-a can produce the same package.json file and two different node_modules tree.
Couple those with incorrectly declared dependency (e.g. using ^ with non-semver packages), it is possible that, in the absence of a lockfile, a node app with dependencies works on one machine but not another, or works now but not in the future.
Imagine this: you built a web app, it works great! You deploy it, push the source code to GitHub, and delete your local repo. Three months later you want to add a new feature to it. So you clone the repo and run npm i && npm build. The build now fails because you now have a different node_modules tree than what you had three months ago when you made the app.
As for merge conflicts, do not just delete the lockfile. Resolve conflicts in package.json first (if any), then check out the lockfile from the base branch (in typical workflows, the dev or master or main branch or whatever you call the shared development mainline branch), and run npm i --packge-lock-only.
References:
> facebook related proxy that might collect your data
Not true (at least no longer).
You can argue whether it will stay as a CNAME, but as far as I understand yarn's governance model, the only person with discretion over that is Maël Nison (/u/arcanin), who was but no longer is a Facebook employee.
run watch on your lib to rebuild on change
use portal in your app https://yarnpkg.com/features/protocols#whats-the-difference-between-link-and-portal
In a new terminal window
$ yarn start yarn run v1.22.5 error Couldn't find a package.json file in "C:\Users\Maximus" info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this comm and.
Wow, another error
​
mastodon@dominicmcclintock:~/live$ yarn install --pure-lockfile
yarn install v1.22.5
[1/6] Validating package.json...
error u/tootsuite/mastodon@: The engine "node" is incompatible with this module. Expected version ">=10.13". Got "8.17.0"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
You still can do that with Yarn 2, you just have to configure it in your repository (in fact, we strongly recommend to use Yarn 2 if you use node_modules, as we fixed layout bugs that plague both npm and Yarn 1).
Yarn 1 received no functional updates, everything merged during the past year was purely intended to fix some migration issues.
We’ve been using yarn workspaces to manage our cdk and lambda functions within their own separate packages (all typescript with node 12 runtime). It’s nice because we can build the packages using separate package specific logic and even utilize other local library (which are also registered workspace packages) as dependencies.
Had some growing pains like trying to use layers for common libs made things more difficult than simply requiring them as a dependency. There were also issues with “nohoist” workspace packages but we’ve found ways around this (webpack). Also, Just upgraded to yarn v2/berry and it was a mess so i’d recommend avoiding that for a little longer but we have it running nicely now.
>Docker
Hi tried to play around using the docker. Not able get frontend running. when i start the container.
Not able to get around the below error. Can you advise?
$ nuxt start --hostname <code>0.0.0.0</code> --config-file config/nuxt.config.demo.js,
/bin/sh: 1: nuxt: not found,
error Command failed with exit code 127.,
info Visit <code>https://yarnpkg.com/en/docs/cli/run</code> for documentation about this command.,
yarn run v1.22.4
Had error like this some time ago.
I had "unused var", too.
Just comment it out or use that unused variables.
Failed to compile.
2:42:20 PM:
2:42:20 PM: ./src/containers/Article/index.js
2:42:20 PM: Line 14:15: 'imageUrl' is assigned a value but never used no-unused-vars
2:42:20 PM: error Command failed with exit code 1.
2:42:20 PM: info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
2:42:20 PM:
2:42:20 PM: If the build failed with a warning about "process.env.CI = true", this is due to "create-react-app" treating warnings as errors when in CI. In order to fix this problem, please either:
2:42:20 PM: - Fix the issues highlighted by the warnings above.
2:42:20 PM: - Or modify the "scripts.build" command in your "package.json" from "react-scripts build" to "CI= react-scripts build"
2:42:20 PM: More information can be found at https://docs.netlify.com/configure-builds/troubleshooting-tips/#build-fails-on-warning-message
Listing some things that only yarn (v1, v2 aka berry sucks) does:
- more concise output of packing that are being build with node gyp instead of outputting the entire build log that most people aren't interested in seeing if it's all successfull anyway
- network timeout retries, pretty big factor
- supporting the "resolutions" field in package.json which overrides how dependencies are resolved for the lockfile. This is in particular useful to lock a version even for transient dependencies (I.e. to fix a CVE issue) or skipping transient dependencies all together (self plug) (don't ask why, but it has its uses)
- yarn workspaces. This is entirely exclusive to yarn and is fantastic for mono repos. Lerna just can't fully keep up (which is why personally I always let yarn handle my workspaces and only use lerna for versioning / publishing and scripting)
- Running anything from "scripts" is just "yarn <scriptname>" rather than "npm run <scriptname>".
- On a related note to above, running CLI tools is the same. This allows for consistency and not having to create a script just to run a CLI tool, or using the npx tool.
Of course there are also cons to note about yarn, but I'm not getting into those rn.
Sidenote/protip: personally I have installed yarn through its own installer and also through nom global, however the npm version is actually v2, npm install --global yarn@berry. I then renamed the installed executable in the bin folder for npm from yarn to yarn2 to avoid the conflict and finally added an alias to my powershell and bash configs: alias ylx="yarn2 dlx". "dlx" is basically yarn's equivalent of npx and new in yarn v2 but also muuuch faster than npx because of how yarn v2 does dependencies (with which I strongly disagree for regular projects... But it's damn useful for this)
> You need a few 100 downloads before it stops flagging you
I renewed the Authenticode signature for Yarn (https://yarnpkg.com/) late last year, and even though Yarn gets a LOT of downloads, it still took several months for "SmartScreen" to stop flagging it as "unrecognised". I think this is finally fixed now, but that was really annoying.
Check https://yarnpkg.com/features/zero-installs/
Yarn V2 uses pnp instead of node_modules. That will result in 6x to 10x smaller package size due to non duplicate dependencies and zipped packages. You can commit your yarn folder to source control.
The version two of yarn, (a competing JS package manager to npm) just came out recently and it uses prolog to allow the user to constrain dependency versions.
Hmm, not sure that got it, I ended up installing it manually.. but may have introduced a bug >sudo npm install -g ts-node typescript
>yarn run v1.21.1 $ ts-node index.ts --help
/usr/local/lib/node_modules/ts-node/src/index.ts:421 return new TSError(diagnosticText, diagnosticCodes) ^ TSError: ⨯ Unable to compile TypeScript: error TS2468: Cannot find global value 'Promise'. index.ts:1:24 - error TS2307: Cannot find module 'yargs'.
1 import * as yargs from "yargs";
~~~~~~~
index.ts:40:5 - error TS2580: Cannot find name 'process'. Do you need to install type definitions for node? Try npm i @types/node.
40 process.exit(1); ~~~~~~~
at createTSError (/usr/local/lib/node_modules/ts-node/src/index.ts:421:12) at reportTSError (/usr/local/lib/node_modules/ts-node/src/index.ts:425:19) at getOutput (/usr/local/lib/node_modules/ts-node/src/index.ts:530:36) at Object.compile (/usr/local/lib/node_modules/ts-node/src/index.ts:735:32) at Module.m._compile (/usr/local/lib/node_modules/ts-node/src/index.ts:814:43) at Module._extensions..js (internal/modules/cjs/loader.js:700:10) at Object.require.extensions.(anonymous function) as .ts at Module.load (internal/modules/cjs/loader.js:599:32) at tryModuleLoad (internal/modules/cjs/loader.js:538:12) at Function.Module._load (internal/modules/cjs/loader.js:530:3) error Command failed with exit code 1. info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Not alone - a big part of the Yarn 2 project was to bring new maintainers into the project (in case I win the lottery, as you say), and so far it's been working. It wasn't possible on the v1 codebase which all agreed was a mess.
Also note that I haven't been part of Facebook for almost a year now, and that Facebook doesn't own Yarn.
You can create a monorepo to share code. You can use Lerna or Yarn Workspaces.
FYI - React code is shared using Yarn Workspaces.
Another way might be to publish to NPM as you mentioned or using Bit (which I haven't used before).
Yes, if you and another package requires different versions. Both will be installed. If you and the package require the same version, only one version will be installed.
Yarn selective resolutions could fix multiple versions, but can also break the dependency.
I dislike (2) for the same reason others said: it increases (really: introduces) the chance of collisions.
If you're doing this, at least check in a Cargo.lock file so it's clear what versions of your deps your stuff will actually compile with. This is a good idea anyway. (Cargo's docs say not to check it in on libraries. I disagree. yarn's advice says otherwise and applies equally well to Rust/Cargo.)
This is horrible advice. Never check in your node_modules folder.
Instead, I strongly recommend that folks use Yarn's "offline mirror" feature to cache the downloaded package tarballs and commit those. This is much better, because:
- There are far fewer files
- Those files are much smaller
- You won't be committing platform-specific build artifacts (such as C shared libraries in
node-sass) - You'll be able to clone and reinstall without a network connection, both for local development and CI
- You know you have the exact package versions needed
I talked about this in my post Practical Redux, Part 9: Managing Dependencies.
If you're a larger team, have multiple teams, or just don't want to commit tarballs, look into setting up an NPM caching proxy / alternative server like https://verdaccio.org/ . I believe Artifactory also has NPM support.
But please, don't check in node_modules.
No, not Lerna and no uploading to npm. I mean this relatively low-level feature from Yarn: https://yarnpkg.com/lang/en/docs/workspaces/ - they say thats more intended to be used by monorepo tools such as Lerna but I used workspaces by myself in that case. The documentation is rock solid, I just followed that and it did work as they described it.
I solved a similar problem by using yarn workspaces. In that project, I hit the AWS 200 resource limit and couldn't create more lambdas. So I split the lambdas over many serverless stacks and put each stack in its own directory as their own yarn workspaces and kept the common code also in its own yarn workspace.
I had to manually start a yarn watch inside the common directory to keep the common packages dist directory up to date. The serverless framework was then building and deploying the lambdas of each stack, with its own package.json and with a reference to the common package as if common were an npm dependency.
One downside was that doing a jump-to-source from within the lambda code into the common code did not end up in the common codes sources but instead in the common codes compiled index.d.ts files.
I've only done 1 library project in TS, but I'll chime in just because nobody else has.
- Path aliases don't get translated when you compile output, and there's a long opinionated issue on this
- I've seen a few monorepos, I think many use yarn workspaces under the hood. It sounds like a good idea if you will have many closely-linked dependencies that need to be tested in tandem. e.g. Make a change in 1 lib and test it out through a couple layers of dependencies.
- I honestly don't know what use case project references are meant to solve so I can't really help there.
- I bundle my Typescript library... Most NPM packages I see do a bundle +
d.tsfile. The only project I've noticed distributing their library as un-transpiled.tsfiles gave me a bunch of build trouble, and I had to turn on--skipLibCheckin tsconfig. Could be just one bad apple, but I feel like most JS libraries since forever have been bundling / transpiling in their distributed packages... so why buck the trend?
Well, you can use 3rd party build tools. And seeing that they are just svg, it should be rather easy.
Sure, that they don't accept pull requests is sort of a problem, but, they still have a lot more icons than Fork Awesome and other fonts probably.
(Stats from their websites) Fork Awesome: 744 icons Font Awesome: 1,535 Free icons and 7,020 Pro icons
Also I would not say that many projects are switching, just look at npm downloads:
https://yarnpkg.com/en/packages?q=font%2Dawesome https://yarnpkg.com/en/package/fork-awesome
While running start-yarn.cmd for hadoop-3.1.2(first time run) I got following error. yarn run v1.17.3 error Couldn't find a package.json file in "C:\hadoop-3.1.2\sbin" info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command. I tried uninstalling npm to check for conflicts but it didnt worked. Am I missing any step?
While running start-yarn.cmd for hadoop-3.1.2(first time run) I got following error. yarn run v1.17.3 error Couldn't find a package.json file in "C:\hadoop-3.1.2\sbin" info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command. I tried uninstalling npm to check for conflicts but it didnt worked. Am I missing any step?
npm does not have any way to delete these files automatically. For yarn, there is <code>autoclean</code>, but it’s for advanced use cases only, and you need to specify what files it should remove yourself.
One cool thing with yarn is that you can do dependency overrides. If for example your dependency 388593 requires version 2.0 of 9378494, which is vulnerable, you can't really override it with npm unless with npm audit fix or manually editing package-lock which will get overwritten. With yarn you can specify that when resolving 9378494 for 388593 it's gotta use v. 3.0 - https://yarnpkg.com/lang/en/docs/selective-version-resolutions/
The easiest way is probably going to be nvm. Yarn can also be installed in a similar manner. Once I finally got them removed from brew it was much easier this way on both Mac and Linux.
Both of these use curl to download a bash install script which is then automatically run. This is not a great idea in general but it can be perfectly fine in few cases, such as this.
According to Yarn's Code of Conduct:
>In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
Is this what you are referring to? - https://yarnpkg.com/lang/en/docs/workspaces/
This setup sounds interesting, is it hard to add new angular projects to the monorepo? Do you still run ng new newappname in your root folder and then do some sort of config?
You have such a lovely style, unrelated but just came from yarnpkg.com and was impressed you've made it so big. It's always nice to have friendly illustrations on otherwise jargon heavy dev sites! Keep it up!
>The upgrade --latest command upgrades packages the same as the upgrade command, but ignores the version range specified in package.json. Instead, the version specified by the latest tag will be used (potentially upgrading the packages across major versions).
Yes, that's typical. However, 99% of it is build tooling.
Note that Yarn's new "Plug and Play" feature can eliminate the need for having a separate node_modules folder for every project:
https://yarnpkg.com/en/docs/pnp
Also, NPM's new tink tool has some similar goals:
AFAIK NPM is still not deterministic, but Yarn is.
If you are using NPM and building each environment separately you probably want to re-use the artifacts from the stage that runs npm install, otherwise you might get different packages!
If you use Yarn, you can selectively override dependency resolution (even in transitive cases):
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/
Also this problem exists in other platform too (e.g. C++). Unless you know the code, you cannot assume which behavior is correct.
Unfortunately, the commands to setup and edit the theme (yarn install & yarn dev) show errors/fail:
$ yarn install
yarn install v1.13.0
[1/5] Validating package.json...
warning [email protected]: The engine "ghost" appears to be invalid.
[2/5] Resolving packages...
[3/5] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[5/5] Building fresh packages...
Done in 8.97s.
$ yarn dev
yarn run v1.13.0
$ gulp
fs.js:25
'use strict';
^
ReferenceError: internalBinding is not defined
at fs.js:25:1
at req_ (/home/me/Desktop/WorldCasper2/node_modules/natives/index.js:137:5)
at Object.req [as require] (/home/me/Desktop/WorldCasper2/node_modules/natives/index.js:54:10)
at Object.<anonymous> (/home/me/Desktop/WorldCasper2/node_modules/vinyl-fs/node_modules/graceful-fs/fs.js:1:99)
at Module._compile (internal/modules/cjs/loader.js:734:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:745:10)
at Module.load (internal/modules/cjs/loader.js:626:32)
at tryModuleLoad (internal/modules/cjs/loader.js:566:12)
at Function.Module._load (internal/modules/cjs/loader.js:558:3)
at Module.require (internal/modules/cjs/loader.js:663:17)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
$
Outside of the lockfile, there's also the fact that Yarn and npm have different feature set. For example, if you have a project that uses workspaces and try to install it with npm, it won't work. Same thing if you use the offline mirror or the resolution override.
Note that it's not only between different package manager: it's safer in general to use the exact same version of a same package manager, for the same reason (Yarn 0.1 doesn't have all the features available in the 1.0, for example). To help with this Yarn ships with yarn policies set-version which enforce the package manager version on a per-project basis.
Thanks! Sure, there should be one for One Dark Pro. I’ll add it. I will probably base it on `zhuangtongfa.material-theme` as that’s by far the most popular version.
Yes, that’s possibly the downside of this approach. For this reason, I try to not include more variations than what I think is needed. One benefit of this approach that I find myself doing often is doing quick adjustments by opening the command palette and simply pressing the arrow buttons. This is also a faster way to check out different variations than typing in numbers and saving.
I’m not aware of any ways of doing this through `settings.json`, but I’m open to suggestions. It would be nice if one could bring up a slider from an icon in the status bar with various sliders. Currently the processing is done in Lab color space using the JavaScript library [culori](https://yarnpkg.com/en/package/culori), and a Node.js script is used to compile all the variants.
Checkout the Yarn install page as it depends on your environment.
What do you mean you don’t have an index.js file? Is this a new project? Did you use react-native init or create-react-native-app? Either one should generate that file for you.
The installation instructions did not work for me..
​
$ yarn build-serve
yarn run v1.3.2
$ pulp --then 'parcel build assets/index.html && http-server dist' build --to dist/app.js
/bin/sh: 1: pulp: not found
error Command failed with exit code 127.
info Visit <code>https://yarnpkg.com/en/docs/cli/run</code> for documentation about this command.
​
SOLVED
yarn run elm make src/Main.elm works, although it overwrites the original index.html.
I removed the global elm binary and use the local one. Currently I'm getting the following error.:
yarn run parcel build index.html
yarn run v1.12.3 $ /home/michiel/trip/node_modules/.bin/parcel build index.html ⠴ Building Main.elm...Unknown Elm compiler option: optimize Could not find Elm compiler "elm-make". Is it installed? error Command failed with exit code 1. info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
edit: I had some issues with nvm and system node, although using yarn.
Looks like you made a mistake while installing yarn. It's that possible? Did you try to install that? If not, did you install something else recently that might have tried to install yarn?
Good point. If you're managing all your shared components in one repo, that's great. We thought about doing that for the project I'm working on here, but we have five apps that share components. We kept coming back to 5-6 PRs for a common change would create too much lock-up for us.
I think you're right on the internal tooling.
I believe Facebook and Google use homegrown tools like Bazel: https://bazel.build/ and Yarn Workspaces: https://yarnpkg.com/lang/en/docs/workspaces/ and then release them publicly. Facebook had so many changes at such a large scale that they had to switch away from Git and use Mercurial: https://code.fb.com/core-data/scaling-mercurial-at-facebook/
The stock info is a great starting point.
https://yarnpkg.com/lang/en/docs/workspaces/
We created a webpack shared "app" aswell with all the configs that the other apps import via relative pathing so all apps get same build process.
npm is a separate package
https://wiki.archlinux.org/index.php/Node.js#Node_Packaged_Modules
You shouldn't install packages via npm globally though, as those files may conflict with other files installed from regular packages via pacman in the future.
However, yarn is the better node package manager. You should use it instead of npm. Yarn will install your global packages by default in ~/.yarn instead of /usr, so you don't need sudo or don't have to set a custom prefix like when using npm. Just add (prepend) ~/.yarn/bin to your $PATH env var or call the executables directly.
https://yarnpkg.com/en/docs/cli/global
idk but I think its faster and better than NPM, more modern and have better documentation https://yarnpkg.com/lang/en/
that is javascript environment for me, I just doesn't know why I choose one or another, I just pick what is work for me.
To make yourself easier next time .
https://yarnpkg.com/en/package/react-redux
You will see something like use it and copy that.
** Just beware most of repo come from github, and sometimes some repo is dead without link to github.
What with between yarn, bower, npm ? Yes all this gizmo text can make your headache including me. The most advise you will see here just remove the node_modules and "yarn install" . Sometimes i just yarn add react-native-xxxx also work. Do remind even you put "react-native link", some repo you need to adjust manually. Don't rely much on "react-native link".Read the documentation first.
Yarn does a pretty good job at this. Of course its own local cache will only have the most recently pulled version of those packages.
https://yarnpkg.com/en/docs/cli/install#toc-yarn-install-offline
There should be some documentation with it, if it has a unix origin it might not be labeled as a text file but simply be called INSTALL or something.
Otherwise,
If it's meant for windows it might/should have a project file which describes to visual c how to build it. It could also be that it's meant to build under a unix compatibility layer for which there should be a 'configure' script. If there is no project file but there is a configure script i'd try to run that under the linux environment. The procedure is usually configure, make and make install
e: project files for visual studio should have an extension of .vcxproj i believe.
e2: i think this is the editor you are talking about? That's written in node.js. I'm not familiar with that. But.. I can try..;
You could download node.js and yarn from https://nodejs.org/en/download/ and https://yarnpkg.com/lang/en/docs/install/#windows-stable
afterwards you should be able to install it by running yarn add slate-editor
You need to download the required libraries when creating a new react app, so by default, yeah you need to be connected to the internet. But yarn (alternative to npm) will cache those libraries on your machine, so if you create more projects, it should be able to do it without internet.
Yes. That sounds about right, and is pretty much what we do. Pull requests will typically involve multiple repos, though, with is a bit annoying. We are considering using Yarn's workspaces feature to get all our projects back under one Git repo (https://yarnpkg.com/en/docs/workspaces), but we haven't had time to work on this yet.
Now there is a link from ledger to the neon wallet...
How to install and use Neo (NEO) ?
Note that for the moment downloading and opening the wallet is reserved to expert users familiar with shell systems. (An official standalone app made by the Neo community devs will be available soon).
Download and open your compatible Neo client wallet go to https://github.com/coranos/neon-wallet
install the required Tools and Dependencies
Node (This project uses the current LTS node version, which is v6.11.0)
Yarn (https://yarnpkg.com/lang/en/docs/install/)
Execute these commands in the project's root directory Setup:
yarn install - Installing node dependencies ./node_modules/.bin/electron -v confirm electron is version 1.7.9 Running :
yarn assets yarn start
I haven't used them yet but it sounds like a use case for Yarn's new feature: Workspaces. https://yarnpkg.com/en/docs/workspaces
"Yarn Workspaces is a feature that allows users to install dependencies from multiple package.json files in subfolders of a single root package.json file, all in one go."
> I also quite like not needing to type run for my non standard commands.
I didn't know about this, it's not mentioned in the docs for <code>yarn run</code>.
The upgrade-interactive command is really handy! When I was using npm I relied on npm-check-updates.
You should try to get more of a "shittywatercolour effect", as seen for example here: https://yarnpkg.com/lang/en/ instead of "I am retarded effect" which you currently have.
The way you described it in your original post, people were probably expecting something like xkcd comics in cartoon style but about basic programming concepts (top answer is about printing said cartoons) but instead you give them mediocre blog posts with very bad quality art.
Yarn is pretty nice.
Edit: I guess I should have written something about it, so here goes. Yarn makes it easy to create identical deployments using the correct version of each module. It also makes it easy to back up all dependencies to an offline mirror and deploy from that.