Publish like there is no tomorrow!
Did you come here in search of new and cool npm packages, which may change your workflow? If the answer is yes, then you came to the right place. If the answer is no, then I present to you cool npm packages, which may change your workflow, even though you were not looking for them.
Short intro
Recently I published my first article under my newly founded publication: Jay Son. It has the ultimate node.js package guide as well as some backstory to tie everything together. I recommend you to check it out, since it contains some insight on our topic today. In any case, here is a link:
Now on to our topic for today. I decided that instead of posting here and there, one line summaries of my public npm career so far, I should use this opportunity to give you a broader review of each package. So here it goes:
The review
I decided to cover my created packages in a chronological order based on time of creation. Hence, we will start with texting:
texting
I have to admit that creating texting was a decision made out of pure frustration. I was a actually working on jsdoctor (which I will cover later) and I couldn’t find a decent package for multiple strings manipulation as I needed. The only package I did find that somehow gave me my coveted result, made me jump through a lot of illogical hoops, so I gave up on it pretty fast.
As for texting, I would describe it in the following manner: it is a package for joining an array of strings with many addition options. For instance, let’s say you want to pretty print the shopping list your wife gave you. You could do it in the following way:
texting(["steaks", "apples", "rice"], {
blockStart: 'My shopping list: ',
lineStart: '> ',
lineEnd: '.',
blockEnd: '---------'
});Here is the result:
My shopping list:
> steaks.
> apples.
> rice.
---------Pretty handy, right? If you think so, you are welcome to check it out here:
constring
This one right here is a tricky one. Either you will be the number one fan of it or its biggest opposition. The reason being the sole idea of this package is to replace one/two character strings with a variable, just to prevent string pollution in your code. Though to be fair, the idea is actually to replace any eligible string constant, regardless of length, purely out of aesthetic reasons.
Here is one way the package allows you to do so:
const { ONE, DOLLAR, EXCLAMATION } = require('constring');
console.log('It will cost you: ', ONE + DOLLAR + EXCLAMATION);You probably guessed it already, but here is the result:
It will cost you: 1$!I truly believe that often, strings stand out and make our code less readable. It is not a huge problem, but a very solvable one , if you are using constring :)
If you think so too, you are welcome to check it out here:
jsdoctor
This one is my baby, the one which pushed me to create the first two packages. It also pushed me to the limits of sanity as lexical code analysis is a fascinating world, but also a very complex one.
The idea of creating jsdoctor originated from my co-workers complaining that in JavaScript, you can’t keep track of how certain objects and variables look like. In their words:
“You don’t know what you get”
When I suggested jsdoc, they claimed that the upkeep is too much of a hassle. While personally I disagree, I decided that maybe a more cost-effective solution is an order. The direction was clear, a tool for generating jsdoc comments on the fly.
Unfortunately, it is easier said and done. Type inference is a very difficult task in JavaScript, as it has certain limitations in that department. And rightfully so. JavaScript was not intended to be a strongly typed language.
The other problem is I can’t read people’s minds, so as far as descriptions go, I can only generate some hard-coded ones from pre-made templates.
With all that being said, I enjoyed parsing my way through code, “deciphering” it and creating a well deserved solid result. While JSDoctor is still not this mind reading documentation tool, it saves a lot of work already. It creates pretty nice templates based on read code and inferred information and I really recommend using it. See for yourself:
/**
* @param {*} a
* @param {number} b
* @param {boolean} opposite
* @returns {*}
* @throws {Error} The first argument wasn't provided
*/
function diff(a, b = 1, opposite = false) {
if (!a) throw new Error("The first argument wasn't provided");
if (opposite) return b - a;
return a - b;
}It was all auto-generated. If you like what you see and want to try it out or you’d like to learn more about JSDoctor, check it out here:
semita
Unrelated to the previous packages I developed, I decided to go for visual data representation. The long-term goal was to create some analysis tools for node.js applications. But a diagram to showcase data seemed like a valid starting point. Thus a hierarchical data visualization package called semita, was born.
Using semita is very easy. All you have to do is provide it a json object with some specific keys. The result however, is something else entirely. Let’s take a look:
You can think of it this ways: there is an easy option to beautify hierarchical data now (you would be surprised how rare it is). If it is something you are interested in, check it out in the link below:
In conclusion
I had lot’s of fun creating those packages and I am very excited to learn what the future holds, for them and for me both 😃. if you still didn’t have the experience of creating any packages or publishing them on npm, I highly suggest you fix it as soon as possible. I also want to remind you to check my previous article about node.js packages creation, as it may further your knowledge and help you down the line (the link is in the intro). Until next time!
