Using npm/Node.js code
While Deno is pretty powerful itself, there is a large eco-system of code in the npm registry, and many people will want to re-leverage tools, code and libraries that are built for Node.js . In this chapter we will explore how to use it.
The good news, is that in many cases, it just works.
There are some foundational things to understand about differences between Node.js and Deno that can help in understanding what challenges might be faced:
- Current Node.js supports both CommonJS and ES Modules, while Deno only supports ES Modules. The addition of stabilized ES Modules in Node.js is relatively recent and most code written for Node.js is in the CommonJS format.
- Node.js has quite a few built-in modules that can be imported and they are a
fairly expansive set of APIs. On the other hand, Deno focuses on implementing
web standards and where functionality goes beyond the browser, we locate APIs
in a single global
Denovariable/namespace. Lots of code written for Node.js expects/depends upon these built-in APIs to be available.
- Node.js has a non-standards based module resolution algorithm, where you can
import bare-specifiers (e.g.
lodash) and Node.js will look in your local and global
node_modulesfor a path, introspect the
package.jsonand try to see if there is a module named the right way. Deno resolves modules the same way a browser does. For local files, Deno expects a full module name, including the extension. When dealing with remote imports, Deno expects the web server to do any "resolving" and provide back the media type of the code (see the Determining the type of file for more information).
- Node.js effectively doesn't work without a
package.jsonfile. Deno doesn't require an external meta-data file to function or resolve modules.
- Node.js doesn't support remote HTTP imports. It expects all 3rd party code to
be installed locally on your machine using a package manager like
npminto the local or global
node_modulesfolder. Deno supports remote HTTP imports (as well as
blobURLs) and will go ahead and fetch the remote code and cache it locally, similar to the way a browser works.
In order to help mitigate these differences, we will further explore in this chapter:
- Using the
std/nodemodules of the Deno standard library to "polyfill" the built-in modules of Node.js
- Using CDNs to access the vast majority of npm packages in ways that work under Deno.
- How import maps can be used to provide "bare specifier" imports like Node.js under Deno, without needing to use a package manager to install packages locally.
- And finally, a general section of frequently asked questions
That being said, there are some differences that cannot be overcome:
- Node.js has a plugin system that is incompatible with Deno, and Deno will never support Node.js plugins. If the Node.js code you want to use requires a "native" Node.js plugin, it won't work under Deno.
- Node.js has some built in modules (e.g. like
vm) that are effectively incompatible with the scope of Deno and therefore there aren't easy ways to provide a polyfill of the functionality in Deno.