DEV Community

Cover image for You, me and package.json

You, me and package.json

Fernando Larrañaga on July 30, 2019

¿Español? Puedes encontrar la versión traducida de este artículo aquí: Tú, yo, y package.json If you have worked in a Node.js or client-side JavaS...
Collapse
 
adam_cyclones profile image
Adam Crockett 🌀 • Edited

You might not know this. 🔥

Package JSON files can have internal variables. Anything you place in any field can be referenced to interpolate anything else in your package.json.

$npm_package_{field} where field is a field in the top level. Just add more underscores to drill deeper. I commonly store constants in the config field to cut repetition within package.json AND get values in process env as mentioned in post.

Collapse
 
xabadu profile image
Fernando Larrañaga

I did not know that indeed! That's an awesome tip, thanks for sharing! ✌️

Collapse
 
sidouglas profile image
sidouglas

This won't work in Windows, unfortunately. Need to use cross-var (npmjs.com/package/cross-var)

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

2 / 3 cases, what about Linux subsystem?

Collapse
 
sqlrob profile image
Robert Myers

Thank you, a nice concise, useful article that's going to help me with my node work.

Something you didn't really touch on, but when would you use yarn vs npm on a new project? I always use what a project was created with, and npm for anything I create, but when should I use yarn for my own projects?

Collapse
 
xabadu profile image
Fernando Larrañaga

Thanks, Robert! Glad to hear the article was helpful :)

On yarn vs npm, while initially there were noticeable differences in performance and features, I guess at this time is more of a personal preference and what works best with your setup, since you can get pretty much the same with both.

I've seen a lot of projects adding lock files for both, which to be honest, seems like a bit of pain to maintain and could potentially lead to having those files off sync regarding the correct versions of dependencies, but it's definitely a possibility.

In general, I'd say, if you're publicly sharing your project, npm would be a more appropriate way to go, since it's the one that most devs, especially beginners, are most familiar with.

Collapse
 
victorcazanave profile image
Victor Cazanave • Edited

Nice article! Although I use npm for several years, I still learnt new things :)

Even though it's considered a good practice to use related names if the package belongs to a certain technology (like using react-{something} for React libraries), it's also recommended to not use node or js in the name.

Why using node or js in the name is not recommended?

Collapse
 
xabadu profile image
Fernando Larrañaga

Thanks! Glad to hear it was useful :)

For the most part, it's considered redundant. According to npm and their recommendation, users can infer that it supports JS by being on npm and having a package.json file, and if you need to specify that it's specifically for Node, you can do so by adding an "engine" entry in your package file.

I would also add, though this is purely personal opinion, that adding js and/or node to the name might lead less experienced users to believe that it's an official package.

Collapse
 
stereobooster profile image
stereobooster

My attempt to document package.json github.com/stereobooster/package.json

Collapse
 
xabadu profile image
Fernando Larrañaga

Nice! Thanks for sharing :)

Collapse
 
qiheme profile image
Quincy Iheme

This was super helpful. Thanks for writing!!!!

Collapse
 
xabadu profile image
Fernando Larrañaga

Awesome, thanks! Glad to hear it was helpful :)

Collapse
 
lirantal profile image
Liran Tal

Nice write-up Fernando!

Collapse
 
xabadu profile image
Fernando Larrañaga

Thanks!