¿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...
For further actions, you may consider blocking this person and/or reporting abuse
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.I did not know that indeed! That's an awesome tip, thanks for sharing! ✌️
This won't work in Windows, unfortunately. Need to use cross-var (npmjs.com/package/cross-var)
2 / 3 cases, what about Linux subsystem?
Nice article! Although I use npm for several years, I still learnt new things :)
Why using node or js in the name is not recommended?
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.
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?
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.
This was super helpful. Thanks for writing!!!!
Awesome, thanks! Glad to hear it was helpful :)
My attempt to document package.json github.com/stereobooster/package.json
Nice! Thanks for sharing :)
Nice write-up Fernando!
Thanks!