\n\nTL;DR Even if you primarily run your JavaScript in Node, Deno is a\nfantastic tool for building and distributing packages on NPM (and\neverywhere else). This article shows how to publish modules to both\nhttps://deno.land/x and https://npmjs.org using nothing more than\nthe deno CLI.
\n
myth: You need to use node and npm , yarn , pnpm , et al. to\npublish packages to https://npmjs.org
Fact: Deno is perfectly capable of maintaining NPM packages. Studies\nconclusively show that maintaining NPM packages with Deno instead of Node is up\nto 900% more stress free.1
\nAs you may or may not know, here at Frontside we’re migrating toward\nDeno as our primary tool for JavaScript\ndevelopment. That means that we’ll not only use Deno\nfrom the get-go to develop our new JavaScript projects and publish\nthem to deno.land, but over time we’ll also migrate our existing\nrepositories that use Node as the primary development tool. But that\ndoesn’t mean we’re rejecting the Node ecosystem – far from it!
\nWe have a ton of NPM packages already\ndeveloped that we and our\nclients critically rely on. Moving\nforward we want all of our new packages to be available to all\nJavaScript developers, not just those that happen to run their\nprograms on Deno. And finally there is our work with\nBackstage, which comprises the lion’s share of our\nbusiness. It runs on Node and will do so for years to come. In a\nnutshell: we have been and are going to continue to be deeply\nintegrated with the Node community for the long haul.
\nBut given this, how will we swap over to use Deno without\nlosing what we have in terms of our existing install base of NPM\npackages and Node applications? Simple intuition tells us we should\nuse Node to develop Node packages and Deno to develop Deno modules:
\nBut as it turns out, Deno has excellent capabilities to build NPM\npackages that we use every day, allowing us to both have our cake and\neat it too. With a slight tweak to how we think about versioning, we\ncan get all the DX goodness of Deno, but our code is accessible to the\nwidest possible audience of developers on both deno.land and NPM.
\nThe key change in thinking that enables this transition is to move\naway from package.json as the final source of truth regarding the\npackage version and to replace it instead with a humble git tag. Each\nreleased version will have a single tag to represent it, with the\nresult that package.json goes from being authoritative to just another\nbuild artifact. In short, moving forward we’re following this mantra:\nIf it doesn’t have a tag, it ain’t a release.
\nWith that mental shift in place, we can implement the following\nscheme:
\nWe’ll spend the rest of this blog post showing how we will do this for\nboth platforms.
\nFor all projects, a release tag is a combination of a “version prefix”\nfollowed by a semantic version number. The most common version prefix\nis the letter ‘\"v\"’, so for example, the semantic version 1.3.5 would be\ntagged with \"v1.3.5\" . The beta version 1.6.0-beta.3 would be tagged\nwith \"v1.6.0-beta.3\".
\n\n💡 While
\n\"v\"is the most common version prefix for a single module,\nmonorepos that contain multiple distributed modules will need to use\na more specific version prefix for tags like“package-a-v,”which\nwill result in release tags likepackage-a-v2.0.0
The deno.land build/publish is almost a gimme since it uses git\ntags natively. All we have to do is create and register the webhook\nfor our module and we’re done! Moving forward, every time\ndeno.land sees a release tag, it will snapshot our source at that\ntag and make that version available to users – in perpetuity.
\nThere’s a little more work to be done getting our package onto NPM,\nbut with a helping hand from Deno, we can do it in just two steps:
\nYou might be asking yourself, “How are we going to take a bare ESM\nmodule implemented in TypeScript and just whip up a script that does\nall the things needed to end up with a valid NPM package?”
\nThe short answer is that the script practically writes itself! That's\nbecause Deno has our backs with a brilliant little tool called dnt or\nDeno to Node Transform. dnt is downright amazing, and its capabilities\nare way undersold. Whether we're creating a new package that we want\nto publish everywhere or we are just migrating repositories from Node\nto Deno, dnt is the secret sauce we use that does all the heavy\nlifting for us.
\ndnt works by taking a single ES module entry point as the input and\ngenerating a feature-complete NPM package containing all its exports\nas the output. Along the way, it does all the terrible, tedious,\nun-fun, and error-prone things you hate about NPM-ing, such as\nmaintaining the list of dependencies, compiling typescript, generating\nsource maps and typings files, creating both commonjs as well as esm\nbuilds, and optionally vendoring any dependencies. The results work\nfor users consuming the package from TS, JS, on the browser or the\nnode – including every possible combination of those – and you didn't\nhave to think about any of it. Magic!
\nI won’t go into all of the details because the dnt setup\ninstructions are very thorough, but as an example, look at\nour build script at\ntasks/build-npm.ts\nin the GraphGen repository. It can build any version of\nour package, but here’s how we would invoke it to build version\n1.0.0
$ deno run -A tasks/build-npm.ts 1.0.0\n[dnt] Transforming...\n[dnt] Running npm install...\nadded 6 packages, and audited 7 packages in 1s\nfound 0 vulnerabilities\n[dnt] Building project...\n[dnt] Emitting declaration files...\n[dnt] Emitting ESM package...\n[dnt] Emitting script package...\n[dnt] Complete!Now that we have the script to build an NPM package from source, the\nonly remaining step is to add a GitHub workflow to be able to call\nit. Here is an example from the GraphGen\nrepository. Each\nstep below is linked to the relevant section in it, but the overall\nsequence is:
\nIt’s about as straightforward as a GitHub workflow can get, and with\nit in place, we can now publish to two locations – just by creating a\ntag. (Trust me, it feels even easier when you try it yourself.)
\nLike many JavaScript developers, we have a heavy investment in the\nNode ecosystem, which means that we rely on NPM to distribute most of\nour code. However, because of Deno’s excellent support for NPM and NPM\ndistribution, we’ve been able to forge ahead with migrating more and\nmore of our repositories so they can use Deno as their primary\nJavaScript development tool – without sacrificing any of our NPM\naudience. Not only is Deno perfectly capable of managing NPM packages,\nbut from our point of view it is actually a more pleasant experience\nthan doing so with Node itself. I hope I’ve shown that if you’re\nthinking of giving Deno a spin it isn’t an either/or proposition. You\ncan happily develop with Deno yet still publish your code to NPM,\nwhere it can be consumed just the way it always was by applications\nrunning on Node. That means that you can adopt it incrementally at a\npace that makes sense for you and your organization.
\nSo what are you waiting for?
\n