Tutorials on Npm Registry

Code dependencies are like Lego's . We're able to pull in other people's code; combining and stacking different packages together to fulfill our goals. Using dependencies greatly reduces the complexity of developing software. We can take advantage of the hard work someone has already done to solve a problem so we can continue to build the projects we want. A development pipeline can have multiple kinds of code dependencies: In JavaScript, we have a package.json file that holds metadata about our project. package.json can store things like our project name, the version of our project, and any dependencies our project has. Dependencies, devDependencies, and peerDependencies are properties that can be included in a package.json file. Depending on the instance where code will be used changes the type of dependency a package is. There are packages that our users will need to run our code. A user is someone not directly working in our code-base. This could mean a person interacting with an application we wrote, or a developer writing a completely separate library. In other words, this is a production environment. Alternatively, there are packages that a developer or system only needs while working in our code. For example linters, testing frameworks, build tools, etc. Packages that a user won't need, but a developer or build system will need. Dependencies are packages our project uses in production . These get included with our code and are vital for making our application run. Whenever we install a dependency the package and any of its dependencies get downloaded onto our local hard drive. The more dependencies we add, the bigger our production code becomes. This is because each new dependency gets included in the production build of our code. Evaluate adding new dependencies unless they're needed! Dependencies are installed using npm install X or yarn add X Packages needed in development , or while developing our code, are considered dev dependencies. These are programs, libraries, and tools that assist in our development workflow. Dev dependencies also get downloaded to your local hard drive when installed, but the user will never see these dependencies. So adding a lot of dev dependencies only affects the initial yarn or npm install completion time. Dev Dependencies are installed using npm install --save-dev X or yarn add --dev X Peer dependencies are similar to dependencies except for a few key features. First, when installing a peer dependency it doesn't get added to your node_modules/ directory on your local hard drive. Why is that? Well, peer dependencies are dependencies that are needed in production , but we expect the user of our code to provide the package. The package doesn't get included in our code. This is to reduce including multiples of the same dependency in production . If every React library included a version of React as a dependency, then in production our users would download React multiple times. Peer dependencies are a tool for library owners to optimize their project size. Peer Dependencies are installed using yarn add --peer X I recently released a course, Creating React Libraries from Scratch, where we walk through content just like how NPM dependencies work, and a lot more! We start with an empty project and end the course with a fully managed library on npm. To learn more click the link below! Click to view Creating React Libraries from Scratch!

npm centralizes third-party, open-source Node.js packages and libraries within a large, online registry. Contributing to the Node.js ecosystem involves no vetting process, which lets anyone publish packages to the npm registry with little effort. Not only has npm's short process for publishing packages led to the explosive growth of the Node.js ecosystem, but also fosters the development of various types of packages: front-end libraries/frameworks, tooling, bundlers, routers, state management, etc. However, this comes at the cost of more packages being released with more security vulnerabilities and less reliability. Despite these concerns, npm continues to introduce new features and statistics for helping developers identify high quality packages. A library author uses npm's command line client to publish their library's package to the npm registry and share it. Once published, npm allows developers to update their projects' dependencies with the latest version of this package or install this package within their projects. Below, I'm going to show you how to publish a package to the npm registry. I will demonstrate this with the rgb-hex TypeScript library. It will be modified accordingly to get it ready for publishing. To get started, you must have an npm account. If you do not have an npm account, sign up for an account here . Within the root of the package directory, run the following command in the terminal: Logging into your account associates your package with your account. You will be prompted to enter your npm username, password and e-mail address. When you publish a package to the npm registry, there are some files and directories, such as a testing suite and coverage reports, that can be omitted from the package. A testing suite validates your library's functionality and coverage reports inform you of areas in your code that lack tests. They are not required for end users to consume your library within their projects. The main benefit of excluding files with .npmignore is reducing the number of files and directories the end user downloads when fetching your package from npm. Ideally, end users should be able to quickly download your package, and your package should not take up unnecessary space on their machines. If your library uses the Jest testing framework, then you would add the __tests__ and coverage directories to the .npmignore file. ( .npmignore ) To further reduce the number of files within the package, you can exclude formatting-related configuration files, such as .eslintrc.js , .prettierrc and .editorconfig . ( .npmignore ) Just think about which files and directories are needed within the package to allow end users to use your library. Whichever files and directories are not necessary should be added to the .npmignore file. Note : If the project contains a .gitignore file, then the files and directories listed within the .gitignore file will automatically be excluded from the package. Alternatively, you could list the files to include within the package via package.json 's files property. The entry point of your library indicates the file from which execution begins when the library is imported. By default, npm searches for a main property inside of the package.json file to determine the package's entry point. For tooling that supports ESM modules, you can define a module property that points to the package's .mjs file. Note : module is not an official package.json property. It is a proposal for ES6 module interoperability in Node.js. Read more about it here . Commonly, your library's generated build will be outputted to a build or dist directory. Therefore, the main and module properties should point to files within either of these directories. ( package.json ) To verify the package's contents before publishing to npm (and whether or not the .gitignore and .npmignore files filter out the correct files and directories), create a tar archive of the package. This tar archive contains all of the files and directories that will end up in the published package. To generate the tarball, run the following command: In the current directory, you will find a tar file named <package-name>-v<version>.tgz . package-name comes from the name property of package.json , and version comes from the version property of package.json . To extract and list its contents, run the following command: The tar -xzf command deposits the contents into a directory named package . Here, we can see that the package.json file, README.md file and dist directory are included. Lastly, to publish the package to npm, run the following command: When prompted to enter a version, press enter to use the version mentioned in the package.json file. If you run into the following error message, then you will need to enable two-factor authentication for your npm account: To enable two-factor authentication, visit your npm account's "Account Settings" page and click the "Enable 2FA" button under the "Two Factor Authentication" section. After you enter your password, npm redirects you to a wizard that walks through the process of enabling two-factor authentication. Enable two-factor authentication for both authorization and updating/publishing packages. Scan the QR code with an authenticator app like Authy . Verify that Authy successfully registered npm by entering a six-digit code generated by Authy. Once two-factor authentication is successfully enabled, you will be shown recovery codes. Save them to a new, empty text file. Without these codes, it will not be possible to recover your account in the event that you are not able to provide the one-time password. Return to the terminal and re-enter the npm publish command. Once your package has been published to npm, you can navigate to your package's page at npm's website. Try publishing your own packages to npm. You can also check out our new course, The newline Guide to Creating React Libraries from Scratch , where we teach you everything you need to know to succeed in creating a library.