![]() It's a good practice (if not a requirement) to later put the actual text of your license-of-choice at your project's root in LICENSE.md file. If you yet don't know what kind of license suits you best, consider checking out this page, where you can quickly understand and pick the best one (SPDX identifiers included!). The string must be one of SPDX identifiers (short forms), like MIT, GPL-3.0 and etc. ![]() It's this string that lets your users know at what terms you share your code. License is a simple and short, but very important field. □ This array of strings will make your package rank higher when your possible users will search through NPM listings by keywords that much the ones you provided. Keywords give you an option to improve the "SEO" of your package. Mentioned file can later be used for your package's NPM page. Of course, it won't be enough and so README.md file at your project's root can be a good idea. ℹ A short description string in your main JSON file can serve that purpose great! It will then be displayed in NPM listings and e.g. It's good to provide your users with at least some info about your package. That's why versioning guidelines like Semantic Versioning have been created. Of course, you shouldn't just drop any new version you think is suitable (especially when your package is used by other people). next, beta, alpha) preceded by a dash and optionally followed by yet another dot and number, e.g. Usually, it comes in a form of 3 numbers separated by dots (.), e.g. □ You should probably have seen all possible version codes by now, browsing the NPM. Because, guess what! - you should/must change the version with every new release of your package! Also, your version string should be parsable by node-semver, meaning that it should have a certain, predictable structure. version, together with name form a unique ID for every release of your package. The second required and no-brainer field. You can use only URL-safe chars - your name will most likely be typed by others in terminals and used as URL at NPM page.No capped letters and underscore ( _) or dot (.The character length of the name should be no bigger than 214 characters including scoping If you have proper NPM organization register, you can use your package with so-called scope e.g.Your name should be unique (when publishing to NPM) ☝.There are only some rules that you must obey when naming your new package: Your package won't function correctly without this compulsory field. I think the name property needs no explanation. We're going to explore package.json as deeply as possible! So, consider bookmarking □ this page for later use as the full-fledged package.json cheatsheet! □ Let's get started! Basics name With all above said, in this article, we'll finally fix this flaw. □ And, because of inconsistent, incomplete or hard-to-read documentations about it around the web, many newcomers often publish their first packages. Of course, it's nothing wrong - you don't have to know the whole specification, but it's good to at least have some clue about what's what. And still, developers' knowledge about such important, seemingly simple JSON file is often limited to just a few fields. Probably nearly every new JS-related project is started by setting up this particular file. I think we all know what package.json is. But, talking about Node.js without mentioning the famous package.json □ would be a sign of big ignorance of the importance of this file. There, as I said, we'll be exploring every single Node.js API in-depth (or at least that's the plan). Recently I started a series about Node.js and its built-in API.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |