Prelude - The magician's apprentice

My dear apprentice,

I'll ask you, do you want to go on a journey with me? It will take us back 15 years into the dark past of the internet.

In the year 2003 when there was no npm, no GitHub, no nothing. All we had was our sometimes loved, often hated SVN and our tiny hosted servers that ran some ancient version of PHP. Development started with opening an FTP client, copying the files (we thought changed) over to our servers, hit reload and started crossing our fingers as hard as we could in the hope that nothing broke.

If we thought we wrote a piece of code we wanted to share with the world, we added an entry to our weblog, uploaded our code snippet, updated our RSS feeds and felt great. Sometimes people approached us via E-Mail or IRC and told us it wasn't working for them. We replied and we forgot. Sometimes we sent them a "new version" via mail but never bothered to update that weblog entry. It was a happy little world. Sometimes we would've liked to know if someone actually used our code snippet. Maybe they even solved this weird thing in IE 5.5 on Mac we never got our heads around because we didn't have a Mac to work on. But overall, it was a happy little flat world. The sun went around us day by day and those sparkling things in the sky every night were clearly some happy little glowing insects far far up there.

But something changed in the years since. We've seen others performing new tricks, we got our new magic wands and we learned those fascinating new spells from all those modern books other magicians wrote. As we adapted to all that we'd learned, we changed the shape of our little open source world. It wasn't flat anymore, we learned that we run in circles around the sun and not the other way around. But most importantly, we learned that we're not alone, all those sparkling insects up in the sky weren't insects. Those were suns and planets like ours, just waiting for us to learn the trick of teleportation and paying them a visit.

With the magical tools that have been created: GitHub, NPM, Bower, Grunt, Webpack, etc. we evolved from being shabby jugglers, we became the Front End Technomagicians!

You see my apprentice, we live in exciting times, but not all those new skills we learn result in happiness. Like all magic, these new tricks have a price. Using them can burn us out, make us feel guilty and they can be a burden that make us question if all of this is worth it and our time.

My dear young magician, I never want you to experience any of this, so I've written this spell book for you. It contains all the magic tricks I've learned to prevent those feelings from rising, all the good magic that takes away most of the painful and dark side effects of Open Source trickery, so that you can focus on what this really should be: Learning, personal growth, making friends and sharing the things you love.

Sincerely,

The grandmaster of abandoning repos

Chapter 1 - Trapped in a time loop

Every project has a start. Once you find a piece of code releasable there should no obstacles in doing so. So we're going to prepare our toolchain once and for all time to not find us being trapped in a time loop repeating the same steps over and over for every project, we're going to release.

Our tiny little project will be a CLI application that displays all upcoming JavaScript and Web Conferences that have an open Call for Papers. We're going to use the API from Web Conferences in 2018 as our data source for this. You can find the final code here.

If you ever feel trapped by a big project not coming to an end, try to remember the Unix Philosphy and break it down into tiny parts that go well together, this way it's going to be way easier to initially release it and maintain it in the future.

Creating a GitHub repo

The first thing that should be done is creating a GitHub repo for our new library. Not only is GitHub the de facto standard for sharing code (there are wonderful alternatives of course), but also it acts as our "backup" drive right from the start. Just imagine that you've worked on a project for weeks without backing up your code somewhere and then your hard drive crashes. Wooops. All that hard work is gone. If we start with a git repo from the beginning, we'll have a fail safe for that worst-case scenario.

We'll go ahead and create the repository, enter the metadata and choose a sane default for our .gitignore file (which is "node" in our case) and license we want to release our code with. After that, we can just go ahead and copy/paste the code that gets shown to us to init our local repository.

NPM setup

Next we should configure our npm client with sane defaults that can be used every time we create a new project locally. There are a ton of parameters that can be set within our package.json , but the most valuable for our case of releasing a new library are: The author's name, their email address, an URL to a public profile page of the author and the default license that gets suggested to us.

Those properties can be easily set from the command line: