Let's say I just recently installed react-native-gifted-chat from npm, and I realized there is another package inside it, how do I access uuid package in that package?
this is inside my node_module folder:
Regularly we just do import ... from 'react-native-gifted-chat', to access package but how to access uuid package inside react-native-gifted-chat without installing uuid package?
The question is: Why do you want this?
I believe that the correct approach should be to depend on uuid directly, if you actually depend on it.
There is no guarantee that future versions of react-native-gifted-chat will depend on uuid, or depend on a version that has the same interface you're expecting.
Also, I believe that npm makes some effort to deduplicate the same versions of packages depended on by multiple things, so you shouldn't concern yourself overly about disk space.
well, I think the best way is to install the wanted packages as new separate packages with npm, because maybe in the future, the devs of react-native-gifted-chat may stop depending on that package, and you will get errors that may drive you crazy before realizing the mistake you have done, so you better install uuid as a new dependency in your project so you will never have to worry about it being removed from react-native-gifted-chat.
Hope i was clear, thanks
Related
I know that there are already a lot of posts concerning the distinction between dependency and devDependency but I didn't find any that explain it for the case of svelte so lets open this one here.
In most of the svelte package like svelte-material-ui or svelte-routing, the installation guide tell to install the package as a dependency. However since svelte will compile this package during the build time, the new library that will use it doesn't need to install this svelte package. So I don't see why it has to be a dependency.
Maybe this question is opinion based but would be nice to have at least a small idea of what to use.
I believe this is personal opinion. If you're not distributing your code as an NPM package, the distinction should be minimal. See, for example, this related discussion.
In my experience with web projects, it's helpful to distinguish between dependencies that are used for building/testing (devDependencies) vs. those that are "used at runtime" (dependencies). You're right that, with Svelte, none of the literal code is used at runtime, but then everything would be a devDependency, so you don't get a useful separation.
The NPM documentation says that the distinction should be production vs. development/testing.
In SvelteKit (the next version of Sapper) there is one major difference between dependency and devDependency: any module used in a (server-side) endpoint must be a dependency. If not, the project may not work when deployed on a serverless platform, although it will work locally.
Otherwise, I prefer to keep everything as a devDependency. I think it makes sense because Svelte is a compiler, and the packages are only needed at compile-time. However, I don't think it would hurt to just put everything as a dependency.
I'm creating an app using Parcel and #material-ui/styles. My app has the #material-ui/styles dependency. I'm also importing my own npm package that I store locally. This package has also the #material-ui/styles dependency but it's peer dependency. I would assume that this package would use the #material-ui/styles package from my app but there are two different instances of the same package which causes the It looks like there are several instances of "#material-ui/styles" initialized in this application. This may cause theme propagation issues, broken class names and makes your application bigger without a good reason. error.
I was describing it here: https://github.com/mui-org/material-ui/issues/15745 but no one is even trying to help me. It's probably not related directly with the package I'm using but the way how bundlers work. I don't know why Parcel is bundling this package two times instead of just doing it once.
The same problem appears when I try to use Webpack. I always thought that peer dependency will work the way I described.
Here is a reproduction repository: https://github.com/lukejagodzinski/mui-styles-reproduction
Does anyone know how to solve this problem?
I ran into the same issue and this helped me: https://github.com/parcel-bundler/parcel/issues/1838#issuecomment-492369750
That basically will remove the duplicated dependency on build time.
Also be aware that you are using TS, so there's one additional complexity on this issue.
I am warned about vulnerabilities in the packages listed in the package-lock.json file of my Node.Js project.
I can follow the advice here and reinstall all the packages with npm install <package-name>, however, I also use other npm projects that use the older versions of those packages, which will not get reinstalled with a simple npm install.
Does it mean I have to go to package-lock.json and manually change all the dependencies to the latest version?
What if they break?
Isn't there a proper way of doing the updates that ensures you won't break the other packages dependent on the old versions?
If the issue is on a package you directly depend upon, you should update it directly and save it to the package.json + lock its version in package-lock.json in the process by doing something like npm install your-dependency#latest --save[-dev]. But beware: there might be breaking changes that will break your code (for example in case the dependency had a major version update inbetween with some deprecations and breaking changes).
But if the issue is from a dependency of one of your dependencies, the very very best way to solve it is to raise an issue (potentially with a PR to help them) with the maintainer of the parent package, then when they provide an update, update the dependency itself in your project.
You can use npm audit to resolve some issues as well (probably not all, and if a sub-dependency version is specifically required by a dependency, it will not update it because it could break things), but the single best way to solve the issue for you and for everybody else is to get the maintainer of the module you want to update its dependencies, when/if they can.
Reinstalling everything will not solve the issue if the dependency is still vulnerable. Installing does not magically fix stuff, people do :-) However, what you may want to do is use npm outdated to list all the packages that have newer versions available and try to update them, one by one, and see if your vulnerabilities are resolved after that (npm audit).
One more thing: it's usually a bad practice to go and change stuff around manually in package-lock.json. This file should be only auto-generated by one of your npm install (or similar) scripts. This file is what is used by npm to resolve the list of exact dependency/subdependency versions on a fresh install, and it is really the single best way to ensure all the people who use or work on this project have the exact same version of all their dependencies, so it better be correct. Always commit your package-lock.json!
I am relatively new to Node.js and NPM, and I have a kind of naive question. I would like to know if there is a way to know if package published on NPM is tested, and if there is away could we automate that process, and if there is tool or framwork that tell me this packages is tested. Also, does NPM require developers to provide a test for their packages.
Thank you
NPM is just a package manager. As they say in their site,
It's a way to reuse code from other developers, and also a way to
share your code with them, and it makes it easy to manage the
different versions of code.
NPM does not require developers to provide a test for their packages.
Best to use a package that has more stars and downloads cos that vouch for the package.
P.S: Never forget that a developer can pull his/her code from npm anytime :)
There is no way to know absolutely for sure, but usually a good indicator is if the author/maintainer has a test script set in the module's package.json. npm does not require modules to have tests.
NPM doesn't require package developers to write tests for their code.
To understand if a specific package is tested, the best you can do is browse the source code of the package: does it have tests? Just unit tests or other types like integration tests and the like? Are these tests ready to run with straightforward commands? Do these tests offer good code coverage of the package? Do they actually test relevant cases?
To automate a process that tells you if a package has been tested, this process will have to make multiple checks within the source code of the package, as there are multiple conventions on how to write, name and structure tests within a Node.js codebase (not to mention the amount of available testing frameworks that can be used). My concern with this approach is how complicated (if possible) would it be to automatically determine if a package is well tested, without actually having a human look at the tests.
I already installed Express for a hello world app, and worked nice.Now I want create a new app, How can I use the already installed Express for that new app instead reinstalling it for that new app with : npm install express
Or do I have to re-install it frome internet everytime I create a new app?
npm install express
...will install Express only into the current folder path that you have in your terminal. If you want to install the package for all Node.js instances, you'll need to run:
npm -g install express
or, depending on your server's security model,
sudo npm -g install express
Sometimes you'll need to link the package if the linking failed (you'll get a "Cannot find module X" error), via:
sudo npm link express
If you want to read more about it, this blog post is a good read.
Use npm install -g express
But it worths adding express to your package.json with the rest of (future) dependencies you will need, so you can type npm install in your project's root and it will automatically install all the dependecies with the specified version and so on.
Don't install Express globally
Locally installing any package that you're going to depend on is generally considered a best practice in the Nodejs community. It comes down to managing dependencies.
See: Nodejs Blog - NPM 1.0: Global vs Local Installation
Consider the following scenario:
Lets say you do a global install of Express for your first project. You're start off using the latest version of the library and everything goes well. Then over time you write 10 more applications that depend on that install. Eventually Express hits the next main version and adds some killer features but they've also introduced a few backwards-incompatible API changes. You'll want to use the latest version for a new project but a global update will probably break all of the previous applications you've created.
In a best case scenario, you'll have 100% test coverage on all your old projects and through hard work and determination you will eventually manage to update/fix everything that broke with the update.
Realistically, nobody has 100% test coverage on everything and it's likely that something the update broke will be missed and accidentally pushed into production. ::cringe::
The scenario I just outlined is what lots of people refer to as dependency hell. It's a common reason why some organizations get locked into a specific version of a framework/application/dll.
With nodejs, it's cheap and easy to handle dependencies individually for each project. Modules generally aren't as monolithic (read huge) like the frameworks you'd expect in other languages.
To install Express locally with dependencies just use:
npm install express --save
Note: The --save flag will automatically add Express and the version number to your package.json file. If you want the module marked under the devDependencies listing instead, use the --save-dev flag.
The exception to the rule:
The exception to the don't install locally rule is CLI applications. It's rare that someone will write code that depends on a CLI application and -- even if they do -- CLI apps only superficially expose the highest-order functions. Unless the CLI has a development API that you're project depends on, it's probably safe and more convenient to install the package globally.
Aside: A library developer's perspective
As libraries are updated and improved it's not uncommon for library devs to change the API between major versions (ex 1.0, 2.0, 3.0) as they get a better feel for how the everything should be structured. When backwards-incompatible changes are introduced it's not uncommon for people to get all finger-pointy and start bickering about 'poor design'. Most of those issues have little to do with the design of the libraries being used. Rather, they're a cause of poor design and version management from the devs that implement them.
The truth of the matter is, it's impossible foresee a best possible design for a library until most of the code has already been implemented and put to use by a larger community. The best projects are those that grow organically, have a large userbase providing lots of valuable feedback, and adapt over time to their user's needs.
Major versions are usually the most exciting time for library devs because that's where we actually get to release ground-breaking changes. All the versions in between only serve to exist for boring maintenance and bugfixes.
One of the greatest benefits of Nodejs is it's small core. The Javascript language itself is well defined so there's little/no chance that updates to the core will break any code. The second greatest benefit of Nodejs is that the package manager along with the common package.json project file format make managing dependency versions as easy and straightforward as possible.
Source: I develop libraries and spend an obscene amount of time thinking about good API design.