Why and how I created edgemodules
Móricz Gergő Apr 3 '17
This article includes self promotion. Deal with it.
Source of idea
Lately, I've been writing a lot of bots for a friend's community.
The bots were made with a node module. The guys writing it were in progress of upgrading their code, and were not pushing the latest(and important) changes to npm.
Me, the average coder, got the package from npm, wrote some code, and watched it crash when specific conditions applied.
When I asked them about the situation, they didn't answer like what you except. They answer was not "Oh hey, we forgot to push it on npm, thanks for reminding us!". No. What they said was "Oh, yeah, just pull the latest from git, it works".
So this was the basic source idea.
2. source idea
What if people want to live on the edge? What if people need new functions? What if people need the latest and greatest for their development? Well, they of course could go 1-by-1, read the repository field from the package.json of all the modules, and clone them, but that's slow and unefficient.
I had to get a name. I first thought of gitmodules, but that doesnt sound like this at all, and it was kind-of taken.
Then I came up with bleedingmodules from "bleeding edge", but:
- It's a long name.
- It's not a friendly name.
So I just thought "Fuck it, it's edge modules, noone will think it's linked with Microsoft Edge".
So I started looking up some npm blog articles of making your own CLI, and they were very helpful. At least the first one.
The command execution was done with shelljs, file management with fs and rimraf.
It was a one and a half hour coding job, 2 hours if we include reading the npm blog.
There are some functions I want to implement in the future:
- Mercurial and other repository type support
- Support for invalid repository fields.
Here's the npm page of the CLI I made.
Here is the first article from the npm blog about making a CLI.
Hopefully you enjoyed this article in some ways.