Imagine that, at the same time, library\u00a0C<\/strong>\u00a0uses another five different libraries to handle different languages and you end up with a scheme like this one.<\/p>\n\n\n\n That\u2019s called the dependency tree<\/em> of your application.<\/p>\n\n\n\n Sooner or later your project will end up with dozens of dependencies (you won\u2019t even be aware of some of them). And what\u2019s even worse, each of those dependencies will only be compatible with certain specific versions.<\/p>\n\n\n\n This situation would be a nightmare to manage manually. A simple update in a submodule might break your dependency tree and your app might not compile. That\u2019s exactly the problem that npm solves<\/strong>.<\/span><\/p>\n\n\n\n When you create an npm library you will create a json file called At the same time, the dependencies of your library will have their own If someone wants to add your library to their project, then they will just need to run:<\/p>\n\n\n\n Magically, all the dependencies of the tree will be downloaded and installed. This system is amazing because in practice you don\u2019t need to care about the dependencies at all.<\/p>\n\n\n\n The main one is that developers lose control of which code they are including in their projects. Concerns about security have arisen in the past and critical systems require a very controlled and strict dependency tree.<\/p>\n\n\n\n Take this example: a newly created project in React Native has more than 1500 dependencies. It is unlikely that more than a few people know them all. If someone introduced some malicious code \u2013 or just a bug \u2013 a lot of developers would probably adopt this code without even knowing it.<\/p>\n\n\n\n Don\u2019t worry. This is a very rare occurrence. However\u00a0it has already happened<\/a>\u00a0a few times.<\/p>\n\n\n\n The fastest and safest way to write code is by\u00a0not<\/em>\u00a0writing it. If you usually need to copy-paste some features among different projects, you might prefer to create a new JavaScript library and write those features only once.<\/p>\n\n\n\n Then, the next time you need to use those features, you don\u2019t need to copy-paste or write them again \u2013 you just reuse your library. What\u2019s more, if you find a bug, you can solve it once and distribute the fix to the rest of your projects.<\/p>\n\n\n\n Once you have written your node module, one of the easiest and fastest ways to include them in your projects is by using npm.<\/p>\n\n\n\n This tool will help you to create a new\u00a0 PS: <\/strong>If you don\u2019t want to fill the rest of the fields now, you can skip them and come back later to add them in the\u00a0package.json\u00a0file.<\/em><\/p>\n\n\n\n Usually you have some code that you have been copy-pasting between various projects and you\u2019re now moving it to an npm module to reuse it in the future . Next you will need to think of the API that you will expose to the world.<\/p>\n\n\n\n Define Your Public API With <\/span>module.exports<\/strong><\/em><\/p>\n\n\n\n The way that you tell npm what your library is exposing is by using You can specify whatever you want in the\u00a0 Then, your code will go to the\u00a0index.js<\/em>\u00a0and will ascertain the value of the module. For example, if inside your\u00a0index.js<\/em>\u00a0you set:<\/p>\n\n\n\n Then coffeMachine<\/em> will be a number with value 42.<\/em><\/p>\n\n\n\n A more realistic approach would be to set this value to an instance of a class:<\/p>\n\n\n\n coffeeMachine<\/em>\u00a0is now an instance of\u00a0BugfenderCoffeeMachine<\/em>\u00a0and you can now do:<\/p>\n\n\n\n The easiest and trivial step is also one of the most important. Having a good Readme<\/em> file ensures that other people will be able to understand what your library\u2019s about \u2013 and how to use it.<\/p>\n\n\n\n You don\u2019t need to be too creative about it, just use a template like this one<\/a> and try to fill all the fields in a clear way.<\/p>\n\n\n\n The users of your npm library will appreciate that you saved them time. Even a future version of you will be happy to have clear docs!<\/p>\n\n\n\n Sign up to npm<\/p>\n\n\n\n If you don\u2019t have a npm account, it\u2019s time to sign up<\/a>.<\/p>\n\n\n\n npm<\/em>\u00a0is a\u00a0command line tool.<\/em>\u00a0Open the console and write:<\/p>\n\n\n\n You can check that you are correctly logged in with<\/p>\n\n\n\n Tip: prior to publishing a new npm package, ensure that you are logged with the adequate user. This is especially important if you use the same machine for work and side projects.<\/em><\/p>\n\n\n\n We are almost ready to publish. But just before we do, we can run a quick local test.<\/p>\n\n\n\n First, navigate to your library file path, the same path in which you placed your\u00a0 Now create a new JavaScript project in your system and again use\u00a0 You can use this process in the future when you plan to update your library so you don\u2019t need to publish every time you want to test new changes.<\/p>\n\n\n\n Now that you\u2019ve created the library and you tested it locally, it\u2019s time to share it with the world.<\/p>\n\n\n\n npm will start to work on publishing your library to the official repository.<\/p>\n\n\n\n When it finishes, the library should be available in\u00a0https:\/\/www.npmjs.com<\/a>\u00a0and every user in the world should be able to install it using\u00a0 If you start using it and other users adopt it, you will also need to maintain it. From time to time you will have to introduce new features or update deprecated code. Whenever you do that, remember to use Semantic Versioning<\/a> (major.minor.patch).<\/p>\n\n\n\n npm eases the process of maintaining your code with the npm versioning tools:<\/p>\n\n\n\n PS:<\/strong> Be aware that\u00a0![\"\"](\"https:\/\/nguenkam.com\/blog\/wp-content\/uploads\/2022\/09\/image-22-1024x465.png\")
<\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/nguenkam.com\/blog\/wp-content\/uploads\/2022\/09\/image-23-1024x451.png\")
<\/figure><\/div>\n\n\n\npackage.json<\/code> in which you specify which dependencies your JS library has.<\/p>\n\n\n\npackage.json<\/code> files, creating a full dependency tree.<\/p>\n\n\n\n$ npm install <your-library-package-name><\/code><\/pre>\n\n\n\nIs There Any Downside of Using a Package Manager?<\/span><\/h4>\n\n\n\n
Why Should You Create Your Own npm Package Libraries?<\/span><\/h4>\n\n\n\n
Creating Your Own npm Package<\/span><\/h4>\n\n\n\n
$ cd folder\/to\/your project\n$ npm init<\/code><\/pre>\n\n\n\npackage.json<\/code>\u00a0asking you for the basic data needed. Some quick tips:<\/p>\n\n\n\n1.0.0<\/code>, however if you are just starting your project you\u2019re probably better off starting with something like\u00a00.0.1<\/code>\u00a0and switching to\u00a01.0.0<\/code>\u00a0when the code has been tested further. Also, other developers using your library will appreciate that your versioning reflects the state of your code.<\/li>reguire('your-package')<\/code>. If you are using only one file,\u00a0index.js<\/code>\u00a0is enough. However, if your project is about to have more files, it is better that you use\u00a0src\/index.js<\/code>.<\/li><\/ul>\n\n\n\n![\"\"](\"https:\/\/nguenkam.com\/blog\/wp-content\/uploads\/2022\/09\/image-24.png\")
<\/figure>\n\n\n\nAdding Code To Your JavaScript Project and Establishing The Public API<\/h4>\n\n\n\n
module.exports<\/code>, an object that should be present in the entry point of your library (usually the index.js<\/em>).<\/p>\n\n\n\nmodule.exports<\/code>. It could be a number, a function, a class\u2026 Imagine you are building the module from the previous sample\u00a0bugfender-coffee-machine<\/em>. When a user types:<\/p>\n\n\n\nconst coffeMachine = require('bugfender-coffee-machine');<\/code><\/pre>\n\n\n\nmodule.exports = 42;<\/code><\/pre>\n\n\n\n\/\/ index.js\r\nmodule.exports = BugfenderCoffeeMachine; \r\n\r\n\/\/ In your app\r\nconst CoffeeMachine = require('bugfender-coffee-machine');\r\nconst coffeeMachine = new CoffeeMachine();<\/code><\/pre>\n\n\n\ncoffeeMachine.prepareCoffee() <\/code><\/pre>\n\n\n\nAdd a README.md File<\/h4>\n\n\n\n
Publish on npm<\/h4>\n\n\n\n
$ npm login # you will be prompted your mail and password <\/code><\/pre>\n\n\n\n$ npm whoami<\/code><\/pre>\n\n\n\nTest Your Framework<\/h4>\n\n\n\n
package.json<\/code>, and use the command\u00a0npm link<\/code>.<\/p>\n\n\n\n$ cd .\/route-to-your-library\/\r\n$ npm link # This adds the project to your local npm registry<\/code><\/pre>\n\n\n\nnpm link<\/code>, but specifying the name of the package \u2013 the same one that you specified in the\u00a0npm init<\/code>\u00a0step.<\/p>\n\n\n\n$ cd .\/route-to-a-new-javascript-project\/\r\n$ npm link [name-of-the-package] # This installs the library in the project<\/code><\/pre>\n\n\n\nPublish<\/h4>\n\n\n\n
$ cd .\/route-to-your-library\/\r\n$ npm publish<\/code><\/pre>\n\n\n\nnpm install <package-name><\/code><\/p>\n\n\n\nUpdating your library<\/span><\/h4>\n\n\n\n
$ npm version patch # From 0.0.1 to 0.0.2\r\n$ npm version minor # From 0.1.0 to 0.2.0\r\n$ npm version major # From 1.0.0 to 2.0.0<\/code><\/pre>\n\n\n\nnpm version<\/code>\u00a0updates the\u00a0package.json<\/code>, creates a commit and adds a TAG to git.<\/em><\/p>\n\n\n\n