This article was originally posted here: https://blog.bitsrc.io/publishing-your-deno-modules-using-github-f2bd86173392

With Deno’s lack of package manager and intent of simply “linking to files anywhere on the internet”, a lot of people in the community got nervous as to how insecure and unstable that approach could be (me included!).

The truth is that yes, this could potentially be a huge problem for Deno developers, but that is only if they don’t do anything about it. And there are so many options out there to make this work that honestly, why wouldn’t they?

According to Deno’s documentation when importing a module, you’re only specifying the URL of the file, so that part is easy, just upload it literally anywhere you have access to and link that URL from your code. But what about versioning?

Package versions

When linking to a URL you’re not really specifying the version of that URL. Or are you? Look at the following import line, in there you can see it has a version as part of the URL (version 0.39.0).

This is how you’d handle versioning in this URL-based scheme. Of course, this is not some obscure feature from URLs or HTTP, this is just about publishing your modules under a URL that has the version as a part of it or use some form of load balancing rule (or webserver rule) to parse the version from the URL and redirect the request to the correct file.

There is really no standard or hard requirement for you to implement while publishing Deno modules, all you have to be sure of is to provide some kind of versioning scheme, otherwise, your users will not be able to lock to a particular one and instead they’ll always download the latest version, whether it works for them or not.

Caution: As you can see, Deno’s packaging scheme is considerably simpler than Node’s and it’s a very valid attempt at copying an approach that’s been used for years now on the front-end. That being said, most back-end languages have a more explicit and arguably convoluted packaging system, so switching to Deno’s if you’re expecting to share your code with others, you’ll have to remember to include the version as part of the URL somehow, or you’ll provide very poor service to your consumers.

Although that sounds understandable, the question now arises: do you really have to have your own web server and configure it in a way that allows you to add a versioning scheme right into the URL, so you can serve your Deno modules in a reasonable fashion?

And the answer to that question is: No, you don’t. In fact, there is already a platform that will do that for you if you allow it to: GitHub.

In case you’re not familiar with it, GitHub allows you to publish your code and share it with others for free, it works with the version control system known as Git and it’s pretty much an industry-standard in many places. They even have an enterprise version, so you could even be using it for your company’s internal repositories already.

The interesting thing about GitHub is that they publish your content using a URL scheme that includes the Git tag name or the Git commit hash as part of it. And although the commit hash is not that “human friendly” as one would like (I.e b265e725845805d0c6691abbe7169f1ada8c4645) you can definitely use the tag name as the package’s version.

To explain this point, I’ve created a simple public repository and published four different versions of a simple “HelloWorld” module into it using four different tags as you can see:

Now, in order to create the tags, all you have to do is to use the git tag command:

//… write your module until you’re done with its 1st version
$ git add <your files here>
$ git commit -m <your commit message here>
$ git tag 1.0 //or however you wish you name your versions
$ git push origin 1.0

Once this is over and the code is pushed, you can go to GitHub, select the main file for the module and select the tag you want to include from the branch selector on the upper left quadrant of the screen:

Once you’ve selected the tag (the version), you can then click on the “Raw” button on the opposite corner (right corner above the code section of the page), this will open up the file without any UI from GitHub and if you look at the URL, you’ll see how the version is already a part of it:

Doing this will open a URL similar to https://raw.githubusercontent.com/deleteman/versioned-deno-module/4.0/hello.ts (notice the bold section is where GitHub adds the tag name, you can change this to reference other versions without having to change anything else) and then, you can use that in your code to import the code.

There are two things to note from this process:

1. Notice how at the top of the code in the above image, I’m importing a local file. That file also gets versioned, thus you don’t have to worry about any local dependencies you might have, they’ll all get correctly referenced if you link to the right version of the main module’s file.
2. With this process, you’re essentially publishing your Deno modules into a free-to-use CDN that is sure to be available all the time. No need to configure it or pay for anything, just worry about your code and nothing else. In fact, thanks to all other GitHub features, you also gain things like ticket management for when users want to report problems, Pull Requests control for when others want to contribute to your modules, and a lot more. Although there are other alternatives out there and you might have your preferred CDN, going with GitHub, in this case, might be a great way of killing several birds with a single (free-to-use) stone.

And that is it, you can now reference that module from your code using the URL and it’ll work thanks to Deno downloading it and compiling it for you!

Conclusion

Although it might sound a bit scary (and trust me, I was right there with you on day 1), having no npm (or any other package manager) is not such a huge deal. As a module developer, you’ll always want to follow certain guidelines to make sure those using your work can be sure it won’t introduce any sudden breaking changes and GitHub already provides the best free platform for sharing your OpenSource code.

So what about you? Have you already started sharing your Deno modules? What process are you using to ensure versioning is actually available for your consumers? Leave a comment down below so others can learn from your experience too!

This article is part of a book about Deno I’m currently writing, so if you want to know more about Deno and how the new packaging scheme works, you can read more about that project over here.

Publish and Reuse React Components with Bit

Bit makes it easy to publish reusable React components from any project to Bit’s component hub.

Need to update a published component? bit import it into your project, change it, and push it back with a bumped version.

Share components with your team to maximize code reuse, speed up delivery and build apps that scale.

Example: exploring React components published on Bit.dev