mj-pa:
A custom Prettier configuration designed for ReactJS, JSON, & JSX.
Introduction
I’ll start this article off with a rather embarrassing confession; until last month, I was unaware that “regular developers” could publish packages to npm. I don’t know why I believed this, and I just assumed there was some stringent checklist or rigorous testing that each bit of code underwent to become an npm package.
Seeking Confidence
Credit goes to the Prettier docs for broadening my perspective. Herein is made a brief reference to the option to publish one’s own configuration file to npm, allowing for reuse across multiple projects and sharing with others. I bookmarked the link for later and continued searching for the answer I needed at the moment.
The mj-pa config is naturally opinionated since it was modeled after and directly extends the Prettier formatting tool, an almost equally dogmatic source.
The concept still intimidated me a bit. As a junior developer, was I even worthy of making a valuable contribution to the excellent npm registry? But see that was just my lack of self-confidence talking. As it turns out, the answer to these types of questions is always, “Yes!”, and this is certainly also the case for any similar ambitions you might presently have.
A Package is Born
As you can see from the photos, I eventually gathered the courage to define my very own Prettier configuration file and publish it to the npm registry.
Which, I might add, if you have never attempted this before, can be pretty challenging! I spent hours poring over the npm documentation and checking Stack Overflow, searching for elusive but straightforward tips and tricks. Lest I digress too much, I shall write in more detail at a later time about the technical side of publishing my first npm package.
Use Cases
While the variables may have shifted over time, the codebases in which I have been using mj-pa have remained relatively similar, due in part to the limited scope of Prettier itself. The formatter works almost exclusively within the JavaScript ecosystem, so, naturally, the best results will be realized when mj-pa is used in a React- or Vue- style JavaScript environment.
Now I realize each developer will have a different opinion, and I am by no means claiming to have written the best config file or discovered the perfect formatting parameters. However, if you decide to give mj-pa a shot, at least now you have the project’s backstory.
And should you decide to make your edits or write an entirely different version, hopefully, you now have the confidence to experiment just as I have done until you decide what works best for you.
Making it Better
Since its release, I have made several updates to mj-pa, and I also published it to the GitHub package registry and the npm registry. The most noteworthy was the recent release of v2.0.0, which introduced several critical adjustments to the previous config.
You may rightfully wonder, “If your config was so great, then why would you need to change it?” The long and short answer is that I didn’t know as much then as I do now, so some of my initial configuration choices were based on inaccurate assumptions or incomplete data.
Let’s face it; opinions are universally fluid. Most developers will change their viewpoints over time, especially if they remain open-minded and willing to consider perspectives besides their own.
Conclusion
Even while we are junior developers, we should never be afraid of trying something new. While there exists a level of understanding that should be achieved before rushing headlong into the unknown, at some point, we have to take the plunge.
I hope this inspires you also to attempt something that has been making you nervous until now! Feel free to add suggestions or ask questions in the comments below, and I will get back to you. Thank you for reading, and don’t forget to try mj-pa!
— killshot13
If you found this article useful, please 👏 to share it!
Follow me (M Rehnert) on Medium and check out my most popular articles below!
Originally published on LinkedIn.
