Re-publishing gimme_readme to npm with GitHub Actions

This week in my Open Source class, my classmates and I were tasked with publishing each of our own programs to a package registry.

When you hear someone say code registry, package registry, or registry, I like to think of these words as representing a place where developers and companies publish their code for others to download. For a more accurate description, you can read this article by Mozilla:

This brings us to the end of our tour of package managers. Our next move is to build up a sample toolchain, putting all that we've learnt so far into practice.

developer.mozilla.org

Why download code from a registry? Why not just go to GitHub?

Individuals familiar with GitHub might wonder, "Why should I even bother posting my tool to a registry? Why not have my users go to GitHub, clone my repository, install the necessary dependencies, build the intermediary files, and run my program?".

Long story short: developers publish their code to registries to make it easy for end users to use their programs.

With that little introduction on why we publish code to registries, let me tell you my process of publishing my JavaScript tool, which was built to host JavaScript code.

You can download my code by visiting its npm registry link below:

gimme_readme is a command-line tool powered by AI that generates a comprehensive README.md file for your project. It analyzes multiple source code files at once, providing concise explanations of each file's purpose, functionality, and key components, all. Latest version: 1.0.0, last published: 16 hours ago. Start using gimme_readme in your project by running `npm i gimme_readme`. There are no other projects in the npm registry using gimme_readme.

npmjs.com

Re-publishing my code to npm

As mentioned in the title of this article, I have already published my code to npm before, and this time around, I was re-publishing my code with new features that weren't included in a previous release.

In addition to publishing the new features that my code has, I also wanted to ensure my end users systems weren't bloated with any extra files from my program.

Here is a picture that shows what my users are currently getting when they download gimme_readme, following the instructions on the `npm registry:

, about the idea of using a .npmignore file to "ignore" files I didn't want to publish.

Literally right after I mentioned the topic, Uday Googled .npmignore, and found an on why one should never use a .npmignore file. To be clear, I wholeheartedly agree with Jeff's article.

Essentially, the idea is that we should be explicit with what we want to publish (whitelisting), as opposed to stating which files we don't want to publish (blacklisting).

Whitelisting the files we wish to publish is simple with npm. All we need to do is edit our package.json file by adding a "files" option, that indicates which files we want to publish for our program.

Below, I've taken a screenshot of package.json's "files" option, which states, "include the src/ directory when publishing this program". I have since committed these changes and these changes are available in my v1.0.0 release of my code.

.

After publishing my code to npm with my updated package.json, users that install/re-install gimme_readme will now have a lot less bloat on their computers! See the difference below:

on GitHub. For exact details on how to do this, you can refer to .

Testing with Uday

As I mentioned earlier, I was working with my friend,

Things look good to me, and most of the options I have for my tool more or less behave the way he expects. But I'll have to repeat this process again, because I have some further optimizations I want to add!

The journey never ends... but that's what makes it fun!

I have also recently heard of ways to optimize my code further. Particularly, I'm invested in learning how to improve my CI and CD pipelines by learning about with regards to GitHub actions. My hope is that these techniques will help me reduce the amount of code I write, and offer some type of performance boost! I don't know much about these topics yet, but you can bet I will probably blog about it soon.

And that my friends, concludes what I wanted to talk about in this blog.

See you next time!