How do I search for packages with yarn?
I want to get a list of results that have the search term in the name of the package as well as in descriptions (similar to how various utilities work like npm search, apropos, apt-cache search).
I tried yarn info <pkg>, but this gave a bunch of json data that was limited to just that package.
Using yarn help and duckduckgo was educational, but still didn't answer how to do this.
there is no command for showing the tabular data format of package information
if you what more information about the packages you can try below commands you will get more information
yarn info package
yarn info package --json
yarn info package#version
yarn info package description
yarn info package time
yarn info package readme
I came here via google and none of the answers really explained anything about WHY search was "missing", so I dug in a bit.
From the Yarn dev's github issue tracker, this exact topic was brought up:
kittens commented on Oct 12, 2016
We've deliberately decided not to add these sorts of commands to Yarn. There's a lot of them that don't actually see much use and the maintenance burden isn't really worth it. If the functionality of the commands is so simple (just opening a browser) then you can just do it yourself. Thanks for the report!
So there you go, it has been intentionally not included and there are currently no plans to include it.
As others have said, you can either use npm's search as both yarn and npm fetch from the same list of packages, or you can use a web-based solution:
https://www.npmjs.com/
https://www.npms.io/
etc
Hope this helps others save a few minutes in their quest for an answer.
I use npms-cli:
Install:
yarn global add npms-cli
Then you will have available /usr/bin/npms and can search like: npms search <desired package>.
Yarn has a website which has information and a detail page for every package in the registry. It’s available on yarnpkg.com/en/packages and provided by Algolia.
Since the npm and Yarn registry are the same, you can also use every tool that shows this data, like npms.io or similar.
Fair disclosure: I work for Algolia and am in charge of the search page of Yarn.
Related
I am following a Microservices course that creates a free NMP account and pushes a package he writes through the course into it and imports this package in other related files of the application like a common NPM module/package.
He also mentions there are other options like using Github or some local Git/version controller, etc.
As I am trying to make a commercial project for my own startup, I am curious to know what is a good/affordable option for a startup company in this situation? Is is still a good idea to use NPM free public account to push some packages and use it through our application?
I think that if you are creating a module that can be useful to the community or part of it, NPM is an interesting option to keep your packages.
If you're uploading not usable packages, but your whole application to npm, then that's messed up, NPM is a package registry. Github, Gitlab, and tools alike should be a more suitable option since those are general-purpose code repositories, not package registries.
Also, be aware that the packages you upload on a free npm account are available to any NPM user. see: NPM Private Packages
From my previous experience, both GitLab and Github offer good free small professional accounts that may be suitable for your case.
As title indicates, I'm working on a project where different members have used different tools (NPM and Yarn) for handling packages and modules etc.
We aim to transition to use ONLY Yarn (not our decision). Would anyone be able to share resources detailing how to accomplish such a thing? Or help quickly walk me through the steps?
I tried googling for answers but every single result is yet another article explaining why you should ditch NPM/Yarn and move your project to Yarn/NPM, without explaining the steps one would need to take to move from using both to just one mid-project. Thanks!
It looks like Yarn has a page talking about how to migrate to it from NPM:
https://yarnpkg.com/lang/en/docs/migrating-from-npm/
In most cases, running yarn or yarn add for the first time will just work. In some cases, the information in a package.json file is not explicit enough to eliminate dependencies, and the deterministic way that Yarn chooses dependencies will run into dependency conflicts. This is especially likely to happen in larger projects where sometimes npm install does not work and developers are frequently removing node_modules and rebuilding from scratch. If this happens, try using npm to make the versions of dependencies more explicit, before converting to Yarn.
As of Yarn 1.7.0, you can import your package-lock.json state, generated by npm to Yarn, by using yarn import.
They use many of the same files and structures. The important thing is to check-in the yarn.lock file and make sure everyone is installing using Yarn instead of NPM.
If you have a build server, you could probably use it to enforce those dependencies, but it would be more work.
After I am installing a root library, such as npm install aws-amplify, sometimes it seems that I need to install its sub library such as npm install #aws-amplify/cli. Why did not npm install aws-amplify install every sub library within it?
What's the npm packaging and installing rule here? can someone help me clearing understand that?
You are mixing up 2 different syntaxes. The #namespace/package is relatively new. It used to be just package, and some packages still use this. In the old way package tend to name themselves 'namespace-package' as some sort ofworkaround.
But that is not your question. Your question is 'why do they even do this?'.
Why wouldn't you just download all the npm package out there? Then you have and can use everything, right? As you can imagine this doesn't make much sense, you will only want to download and use what you need. Think of this quote from Joe Armstrong:
You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.
The quote is a entirely out of context since it is more about not using classes, but it still kind of applies to this. At lot of packages will offer you a core package and the option to add sub-packages based on your need. Like in your example, someone might not need #aws-amplify/cli, this way he doesn't have to download it.
Hi I have made some custom adjustments to a node_module's files to get it to meet client requirements. These changes obviously are not in the packages source code so I want to avoid overwritting them if I need to update npm packages. Is there a way to do this? Maybe something similar to a git ignore?
Modifying a npm package directly is not recommended and could lead to multiple issues, the way to go about this is either contribute your changes to the original source code on GitHub if other would find the code you wrote useful, either that or you could make your own fork of the package and use that as a dependency instead.
You can install your own package by using the tarballs provided by GitHub.
npm install https://github.com/<username>/<repository>/tarball/master
I use npm scripts a lot for my javascript/node projects (npm start, npm test, and npm run build and others), and I was wondering if there is something similar for elm-packages, or if we should use npm scripts instead, and if I have to do it, why do we need a package.json and a elm-package.json?
The quick answer is that (as of May 2017) there's not support for this in elm-package.json.
As for the future: Evan Czaplicki has said on elm-dev mailing list that the file format and functionality will get revamped a little bit (probably with the 0.19 release), but most probably mainly with regards to application vs. library distinction. Based on that, I don't think elm-package.json will get this functionality anytime soon.
I think most devs have some node stuff running to handle their dev environment (e.g. webpack stuff) so you will always have package.json available for such scripts anyway.
There is a question about whether elm should embed its dependencies within package.json but, while most dev instances would have package.json, anyone just trying out with elm-reactor would not. So I think the present situation is here to stay, and enables you to do what you want.