Node.js has several built-in modules that can be used without any further installation. When I write a package that requires these, I wonder if I should add them to the “dependencies” field of the package.json.
No you do not need to add them to your dependencies, and you should not add them to your dependencies. NPM uses this list to fetch modules from the repository, but built-ins don't need to be fetched since they are already provided by Node. As noted below there can be conflicts with package names in the repository.
Related
I have been using typescript for a little while in node.js projects. I understand that for many npm packages there is separate #types package for typescript type definitions.
My question is: how can I know that the #types package is up to date with the latest version of the actual package when they are maintained separately?
For example there is npm package better-sqlite3 with no typescript definitions and then a separate type definition package #types/better-sqlite3. How user of the package can know that types match the current version of the package?
In this answer here it is said that "TypeScript types for JS packages is best effort and depends on Community interest in the package". This sounds a bit scary.
If the package developers maintain the definitions themselves, there's no #types, d.tss are just building in package distro
If there's #types, you may check the last update date of both packages (#types have Last updated in readme), the #types probably was correct at the time when it was last updated.
If the #types is outdated, you may update if yourself and even publish on #types, that's what "TypeScript types for JS packages is best effort and depends on Community interest in the package" means
The types package shouldn't be maintained separately. The author of the package should be listing the corresponding types package as a dependency which means the correct version of the typing should come along when you install the top-level package.
REF: https://github.com/Microsoft/types-publisher/issues/81
Edit: As pointed out in the comments by #Gwydion, there are some packages that are community maintained outside of the originating package. A good example is:
https://www.npmjs.com/package/better-sqlite3
It would seem likely the following package is the correct types package:
https://www.npmjs.com/package/#types/better-sqlite3
But, it's not necessarily obvious either. It would be nice to have to signal to verify that this is the correct package.
Here is what I did:
I visited the originating npm package page, taking note of the repository URL which is: https://github.com/WiseLibs/better-sqlite3
I visited the repository URL of the type package, which is: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/better-sqlite3 (this URL was listed on the type package's npm page under Details)
Open the index.d.ts file located there. At the top it lists: Project: https://github.com/JoshuaWise/better-sqlite3.
NOTE: https://github.com/JoshuaWise/better-sqlite3 redirects to https://github.com/WiseLibs/better-sqlite3 which matches what we found in #1 above.
Currently I am developing an NPM module which focuses on the use with Node.js. It requires the types of an external package (#types/package), but not the package itself. The types are currently located in the devDependencies, like every other type files. But when I install the library from git and use it with typescript, it tells me that exactly the external packages's types are not available, which seems logically to me. Is there a way to bundle these types within the NPM package itself?
Adding the types to dependencies would solve this, I think, but I do not want to store it as a default dependency.
The other way is to copy the type definitions to the src folder first and use them directly. This seems to be complicated and not intended.
Do you have any suggestions? Thanks and cheers!
I understand that packages hold several modules, but I'm starting to get confused as to if packages and modules are dependencies. Also, libraries to me maybe seem like packages you install via NPM, Nuget, RubyGems, Bower, Homebrew, or Chocolatey. So are libraries packages? Dependencies are something you need to load within your application, to have a certain functionality, but aren't some libraries(jQuery) seen as a dependency? So yea, what are the differences between these concepts?
Libraries are just a bunch of code anyone can use. For example, React.js is a JavaScript library for building front end components.
If I decide to use this library in my app, then React will become one of the modules (aka an installed instance of the library) that my app depends on. So dependencies are pretty much all of the libraries your app depends on, in order to run the way you expect it to run.
I asked the same question you did about dependencies, and I learned that it's a matter of understanding how these terms relate to one another rather than finding isolated definitions for each of them.
Hope this helps!
Basically a package is a pack with some features which fullfills some functionality of your app.
Once you install any package using npm then the package is installed as a dependency in your app inside your package.json file along with its modules(aka libraries consist of classes) stored inside node_modules folder.
I hope its clear now.
At our company we have at the moment 5 web applications that are built using Gulp. For Gulp, we have a common buildfile that all applications use (and override certain parts of it if needed).
This makes it very easy to add features or fix bugs in all projects at the same time. However, I still need to edit the package.json file in each project separatly if I want to add a new npm dependency or bump a version for an existing one.
What I would like to accomplish is to a "base file" where all the common dependencies are configured, and the I would like to import that into the "local" package.json in each project. It would also be nice if each project could add more dependencies than the ones registered as common.
Is it possible to do this?
No, and it's a good thing that it isn't. You need to declare your dependencies explicitly on each project.
What you can do, if your build process is a shared API, is to extract your build script into an npm package of its own, and include that in the package.json of all other projects, and use it in them (coding it in a way that allows for overrides)
Then when you need a new dependency for your common build, you only need to change it once. (Note that with this, you'd still need to make sure your build package version is up to date in all other applications)
I've been installing a few node packages and what I noticed is that NPM creates a bunch of duplicates.
For example, I first installed mongoose, which installed a bunch of dependencies, naturally. Then I installed the mongodb package, which also came with bson as a dependency. Due to overlapping dependencies, I have the following anomaly:
Mongodb is present in the following directories:
/usr/local/lib/node_modules/mongodb/
/usr/local/lib/node_modules/mongoose/node_modules/mongodb/
Also, bson, a dependency of mongodb is present in both of these:
/usr/local/lib/node_modules/mongodb/
/usr/local/lib/node_modules/mongoose/node_modules/mongodb/
I realize these are only files of kilobytes, but I feel like this might create a lot of redundancy end I might end up with a very complex tree similar to the following:
/usr/local/lib/node_modules/[something1]/node_modules/[something2]/node_modules/[something3/.../.../node_modules/[somethingX]/
In this scenario a given [dependency] might be present on X levels under /usr/local/lib/node_modules.
My major concern is related to updating these modules. I do not find it hard to imagine to have concurrent modules of different versions installed at the same time.
Wouldn't it be easier to just put everything directly in /usr/local/lib/node_modules/ and then cross-reference dependencies?
The problem is when mongoose is only coded to work with say v1 of mongodb, and you've coded your app to work with v2 of mongodb - as such, it installs and loads up both versions so it all works. We can do this easily in node, as the require module way doesn't pollute the global namespace, unlike the browser - which makes managing and including the right dependencies a royal pain due the global namespace pollution.
Now if your package.json and mongoose's package.json allow the same mongodb version (your can specify a specific version or ranges), then doing a rm -Rf node_modules; npm install will only install one copy of mongodb, rather than two. However as said before, if multiple versions are specified, multiple versions will be installed and loaded.