How do I identify npm packages that are not necessary so that I can remove them from my app?
The scenario is a situation that, I don't think, is unique where the former guy who's no longer in the team put a bunch of stuff in the package.json file and I'm not familiar with all the packages in there. I do want the app to be as lean and clean as possible and would like to remove anything that is unnecessary. I may find out that all the packages in the package.json are necessary but I do want to make sure of that.
Is going through each package and learning what it does and removing it to see if anything will break my only option in identifying the packages that I can remove or is there a better way?
npm install -g depcheck
then:
depcheck
Related
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.
I have a web app that uses npm to install a big list of dependencies.
I want to make a branch that will...
a) permanently freeze all dependency versions,
b) work when checked out, without having to run npm install (i.e. unable to retrieve libraries from the internet), and
c) allow a developer to fix bugs.
It seems like committing /node_modules to the repo accomplishes this, but I do not have enough knowledge to know that this is really the correct answer in all situations.
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.