CodeinWP CodeinWP

npm for Beginners: A Guide for Front-end Developers

Unless you’re an absolute beginner to front-end coding, then you’ve probably heard of npm. And npm for beginners is a subject you’re looking into.

Maybe you’ve clicked through to the GitHub repo of a tool of some kind. You then noticed the installation instructions had a couple of different possibilities, including something like this:

npm install some-tool

In addition to that, there’s usually something like “download the script and include it at the bottom of your page using <script> tags”. Many of you probably go for that latter option.

There are tons of developers that have incorporated npm in some way into their workflow. But I’m guessing there are just as many developers and new front-end folks who are confused about what npm is, and why you’d want to use it.

I’ve been doing some extra reading and research on npm for beginners, and I thought I would walk through most of what I’ve learned in this tutorial. I don’t consider myself a super-expert in all the subtleties related to npm. But I do think this npm tutorial should serve as a good starting point for those who have little or no knowledge of the subject and its benefits for front-end projects.

What is npm?

In brief, npm (stylized in lowercase, so it’s not correct to write it as “NPM”) is a package manager for JavaScript. It stands for Node Package Manager. The official documentation explains that npm is three different things:

  1. The website
  2. The CLI
  3. The npm registry

The website is where you can browse packages, read the docs, and find general info on npm for beginners.

The CLI (or npm client) is a tool installed on a developer’s machine. It allows you to publish packages, install packages, and update packages.

The registry is a database that holds the information and the code for the packages.

Note: A “package” is just another way of saying “JavaScript plugin” or “module”. It’s a bit of a buzzword, but it’s an appropriate term because often packages consist of multiple files.

The rest of this article will go into more detail on the npm registry and using the npm client. The video below is a good starting point too:

Installing Node.js and the npm Client

One of the things that’s somewhat intimidating to designers and those who don’t come from a strong programming background is the fact that npm is used via the command line. But it’s not that big a deal for the purposes of just doing some basic package installing and updating.

To start using npm, you have to do two things:

  1. Install Node.js
  2. Install the npm client

Fortunately, when you install Node, the default installation settings will install the client too. This means you can do both these steps in one shot. You may have Node installed on your machine already. To find out if this is the case, type the following in the command prompt, which spits out the version number for your Node installation:

node --version

In my case, when I started writing this article, I was using a fairly old version compared to what was currently available. It was clearly time for an upgrade. If you do a clean install, you’ll have the option to install either the “recommended for most users” version or the version with the latest features (which I assume is similar to a nightly build).

For the purposes of just getting up and running to learn how to use npm for front-end development, I’d say install the recommended version. As mentioned, when you install Node.js, the installer will automatically install the npm client.

As pointed out in the above video, after you install node along with the npm client, it’s possible that the npm client will be out of date. To ensure you have the latest npm client, do the following (as weird as this looks):

npm install npm --global

That command says “use the npm client to install npm”. The --global part is a flag that tells the client that you want to install it globally (more on flags later). When that’s done, you can check the version number of your npm client:

npm --version

To confirm that your version is the latest, you can view the releases on GitHub. The last version with a green “Latest Release” label on it is the one your system will update to if all goes well.

Using npm to Install Packages

You need to follow the above instructions only once, of course. Then you’ll be ready to use npm on your machine for all projects. But it’s somewhat annoying to have to do all that. It’s simple enough to just download a script or plugin manually or include it using a CDN link. In a way, front-end development feels like a Rube Goldberg machine – we’re jumping through all these hoops to do simple tasks. But, as I’ll discuss later in this article, npm has some significant advantages over the traditional way of using scripts. So it’s not as bad as it might seem at first glance.

In the meantime, let’s look at how you can use npm to add JavaScript modules and other packages to your projects.

As I mentioned at the beginning of this post, even if you’ve never used npm, you’ve probably seen it before. Possibly when you look up some kind of tool on GitHub, or on the tool’s documentation site. For example, let’s say you’re interested in trying out Modaal, the popular accessible modal window plugin. In addition to the usual way to install it (download the script, include the CSS manually, etc.) developers have the option to install it via the command line using npm:

npm install modaal

This option is available for any tool in the npm registry. So this might be where many front-end folks, designers learning to code, and web development beginners might have some trouble. For example, when I first saw one of those npm install commands, my first reaction was twofold:

  1. Where do I run this command (i.e. which directory)?
  2. Specifically what does this do?

To answer that first question, remember that earlier when I installed npm, I used the --global flag. If you’re installing something globally on your system, then you don’t need to worry about what directory you’re in. But in the case of something like Modaal, you want to install it in the directory of the project that’s going to use it.

So let’s say you have a project called “Photo Gallery”, which might be a photo gallery app you’re building. That project might live in a directory called photo-gallery. Using the command line, you’ll navigate to the photo-gallery folder and execute the command I showed you above. This installs the Modaal plugin (or any other package you want to install).

This alone is a nice time-saver. You don’t have to download the files yourself. You don’t have to figure out if the files need combining. And you don’t have to worry about any missing CSS files. The npm registry pulls the whole thing down using a single command.

Now here’s where things get a little sticky for front-end developers.

What Does npm install Do?

From the perspective of a front-end developer or designer who wants to drop a script into a project and start writing code, the way npm installs packages is a little strange and not as plug-and-play as you’d like.

In the case of my fictional photo-gallery app, what happens when I use npm to install Modaal? Here’s the resulting folder structure:

├── photo-gallery/
└───── node_modules/
        └───── modaal/
                ├───── demo/
                │       ├───── css/
                │       ├───── img/
                │       └───── js/
                ├───── dist/
                │       ├───── css/
                │       └───── js/
                └───── source/
                        ├───── css/
                        └───── js/
                               └───── lib/

In this example I left out the files inside the directories, so this is only the folders. As you can tell, this is a little confusing. You might wonder:

  • Why is everything inside a node_modules folder?
  • What’s the difference between dist and source? What is lib?
  • Can I just point to the files inside node_modules? Or do I have to manually move them up to the root of my project folder? If I have to move them, then why even bother using npm to install the whole thing?

These are legitimate concerns. And these are questions I’ve asked and that I’ve researched to help me understand why npm works like this. So I’m going to try to explain things as best I can, based on my research, testing, and experimenting.

dist/, src/, and lib/

First of all, the difference between the dist/ and src/ directories, as explained in this Stack Overflow thread, is:

  • src/ (or source/), is the raw code that you would read and/or edit, before any minification, concatenation, or other compilation tasks.
  • dist/ means “distribution”, and is the minified and/or concatenated version of the code that you deploy to your production sites.

For the most part, these are matters outside the scope of npm in general. This is more about code and project architecture. Modaal has chosen to follow this pattern. Not all packages installed via npm are going to have this structure. But it might be good to be familiar with these concepts if you’re just getting started with managing front-end dependencies.

As for the lib/ folder, “lib” stands for “libraries”. That’s where Modaal has chosen to put its own dependencies. In this case, the only dependency is jQuery. Again, you might see a slightly different structure in other cases.

If you install Modaal yourself, you’ll notice that installing it via npm brings down these folders and a whole bunch of other stuff too, not just the files you plan to include in your project.

What’s up with the node_modules Folder?

In order to understand why npm throws everything into a directory called node_modules, you have to first understand that npm is, first and foremost, a package manager for developers who write JavaScript on the server. That is, Node.js developers.

When a Node.js developer wants to use a package in their project, it’s more or less a two-step process. First, they install the package via npm, then they include it in their project with a line like this in their JavaScript:

let examplePackage = require('example-package');

Using the require() function makes their script look inside the node_modules folder for that specific package, or module. You could think of this like an include file in PHP, if you’re familiar with that. Or, closer to home, like a function reference in client-side JavaScript (which is more or less what this is). The above example will expose the examplePackage variable as an API that uses the functionality of the example-package module, whatever that is.

And please note that Node.js (i.e. server-side JavaScript) is not my area of expertise. This is my attempt at a basic overview of what is happening, to help you understand why front-end packages installed via node work the way they do. Feel free to correct me if I’ve misstated anything here.

If you want to read up a little more about npm, folders, and the node_modules directory you can do so in the npm docs.

How Does the node_modules Folder Work on the Front-end?

Here’s where things get a little complex if you’re using npm to install and use stuff exclusively for client-side scripting, or even for CSS. Yes, you can use npm to install basically anything that you need on the front-end, including CSS-only packages. Let’s use a popular example.

In the fictional photo-gallery project, if I decide I want to include Normalize.css, the ubiquitous CSS reset alternative, I would do this:

npm install normalize.css

Now I’ll have the following additional resources in my app’s directory structure:

├── photo-gallery/
└───── node_modules/
        └───── normalize.css/
                 ├───── normalize.css
                 ├───── package.json

These would be in addition to the Modaal resources previously installed, but I’ve left those out for brevity. As you can see, a folder called normalize.css has been created, and inside that folder are five different files. The one I’m most interested in is normalize.css.

So how exactly do I use this file? If I leave it where it is, then I’m going to have to do the following with my <link> element in my HTML:

<link rel="stylesheet" href="node_modules/normalize.css/normalize.css">

That’s ugly and not great to work with. And that’s beside the fact that I commonly put all my CSS files in a css folder at the root of my project. Also, I don’t care about all that other stuff that’s installed; I want only the CSS.

At this point, unless I know any better, the only option is to copy the CSS file from inside node_modules/normalize.css/ and paste it into my css folder. From there, I might have a build process in place that combines and minifies my CSS (more on this later).

Here would be a good place to discuss why using npm is better than just grabbing stuff directly from repos and whatnot. But before I do that, there’s something else I’ve omitted so far that I should explain.

Installing Packages with Optional Flags

When I installed Modaal and Normalize.css, in both cases I just did a clean npm install [package] with no other commands. In order for this to be useful, I need to create a package.json file at the root of my project folder. The easiest way to do this is using the following command, which I would execute in the terminal inside my project folder:

npm init

This command will initialize a package.json file for me, creating the JSON file in the root of my project folder, and ask me to add some info to the file. Assuming I had not yet installed any packages, my package.json file should look something like this after I answer all the questions prompted by the init command:

  "name": "photo-gallery",
  "version": "1.0.0",
  "description": "My photo gallery app.",
  "main": "index.js",
  "dependencies": {},
  "devDependencies": {},
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  "author": "Louis Lazaris <my@email.address> (",
  "license": "MIT"

At that point, I can add the two packages using the following command:

npm install modaal normalize.css

As a shortcut, I’ve installed them both using a single command, which will update my package.json file. Here’s what it looks like now:

  "name": "photo-gallery",
  "version": "1.0.0",
  "description": "My photo gallery app.",
  "main": "index.js",
  "dependencies": {
    "modaal": "^0.3.1",
    "normalize.css": "^5.0.0"
  "devDependencies": {},
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  "author": "Louis Lazaris <my@email.address> (",
  "license": "MIT"

Notice the “dependencies” section has been updated to include the two packages I just installed. If I didn’t want to list them as dependencies when installed, I could use the --no-save flag. Note that this is a change starting in npm 5. Previously, npm required the use of the --save flag in order to include the packages as dependencies in my package.json file, but now the default doesn’t require the flag with the install command.

Another flag commonly used when installing packages is --save-dev. This adds the package to the “devDependencies” section of package.json. The difference is that the default without a flag is used for packages that your app requires in order to run, while --save-dev is for packages used for development purposes (linting, unit tests, and so forth).

Another thing I should mention here is that many of the flags I’ve used in the examples in this post have abbreviated versions. So:

  • --version abbreviates as -v
  • --global as -g
  • --save-dev as -D

Note that the “d” for “–save-dev” is uppercase while the “g” for “–global” is lowercase. You can see a full list of flag abbreviations here.

Benefits of npm: Replicating Builds

As I mentioned earlier, there are benefits to using npm to install packages as opposed to just grabbing the files manually.

First of all, when I identify packages as dependencies in my package.json file (i.e. by installing without a flag present), this means I can share my project with another developer and that developer will be able to reproduce the full project, with dependencies, using a single command:

npm install

So if someone has a copy of photo-gallery, but doesn’t have the dependencies installed, all they have to do is navigate to the photo-gallery directory and run the above command. As long as package.json lists the dependencies, npm installs them automatically. This means I can install dozens, or maybe even hundreds of packages with a single command.

As an example, if you used Git to grab a copy of UglifyJS2, it wouldn’t work unless you first used npm to install the dependencies (in this case, there are currently 4 listed in its package.json file). The dependencies don’t live in the GitHub repo for that project but npm allows you to grab them all using that single command (npm install).

You could mimic this behavior locally by deleting the node_modules folder in any project and then doing npm install in the root of that project. All that’s required is that you have the dependencies listed inside package.json, and npm will pull them in re

Benefits of npm: Updating Packages

Another benefit of using npm is that it allows you to update any package to a newer version with a single command.

For demonstration purposes, let’s say I was using Normalize.css version 4.0.0. If I want to update Normalize.css, I simply have to run:

npm update normalize.css

But hold on! In this case, I didn’t get the latest version of Normalize.css (which, as of this writing, is 5.0.0); I got version 4.2.0.

When you update a package with npm, you’re not updating to the latest version; you’re updating to the latest version that will not have potentially breaking changes. The npm client recognizes this by means of the version number, which uses Semantic Versioning, or SemVer. A detailed discussion of Semantic Versioning is beyond the scope of this article, but many developers encourage this method of versioning for this reason. Hugo’s article on the subject might be a good place to start if you’re not familiar with SemVer.

If I want to view version details on all my project’s out-of-date dependencies, I can use the outdated command:

npm outdated

Running that command inside a project directory will output something like this in my terminal:

Package        Current  Wanted  Latest  Location
normalize.css    4.0.0   4.2.0   5.0.0  photo-gallery

For full details on what all that means, see npm-outdated in the npm docs. But in a nutshell, the “Current” column identifies the version number of an installed dependency; the “Wanted” column tells me what version I’ll be able to update to safely (using npm update); and the “Latest” column tells me the most up to date version that lives in the npm registry. If I had other out-of-date dependencies, it would list those too. But in this case, I had only Normalize.css. My Modaal installation was the most up-to-date version as of this writing.

As a side point here, what if I want to be able to update to the latest version of a package, even if it’s a major version update with potentially breaking changes? I do this by changing my package.json file’s dependencies to look like this:

"dependencies": {
  "modaal": "^0.3.1",
  "normalize.css": "*"

Notice instead of a version number for Normalize.css, I’ve included an asterisk symbol. This tells the npm client that I’m willing to accept major version upgrades, regardless of breaking changes. For Modaal, I’ve kept it the same, so it won’t install a major release if I update later. Now if I run npm outdated I get the following:

Package        Current  Wanted  Latest  Location
normalize.css    4.0.0   5.0.0   5.0.0  photo-gallery

There’s a lot more to discuss when it comes to version numbers and npm, and it’s certainly something I’m getting more familiar with. In the meantime there’s more info, including a screencast on this subject, in the npm docs.

Benefits of npm: Productivity for Teams

As explained in the npm docs:

[npm] makes it possible for your team to draw on expertise outside of your organization by bringing in packages from people who have focused on particular problem areas. But even if you don’t reuse code from people outside of your organization, using this kind of module-based approach can actually help your team work together better, and can also make it possible to reuse code across projects.

This sort of thing is still possible using manual copy-and-include methods, but that’s just not practical for a growing code base and across a team of developers.

So npm will allow you to not only use other people’s code available on the npm registry, but it’s an easy way to track dependencies and reuse code across different projects.

In short, npm encourages modular code. Wes Bos explained the benefits of modules nicely:

JavaScript modules allow us to chunk our code into separate files inside our project or to use open source modules that we can install via npm. Writing your code in modules helps with organization, maintenance, testing, and most importantly, dependency management.

Although he was specifically writing about ES6 Modules, the same basic principle applies: It’s easier to deal with code that’s separated into pieces, like building blocks. And the npm ecosystem encourages this type of coding.

Getting Back to the node_modules directory

Earlier I discussed the node_modules folder and the fact that npm installs every package in that location. It’s clear that from a front-end perspective, this isn’t the most practical setup. And the folks at npm have acknowledged as much:

This is a pretty obvious problem. The node_modules folder is where npm puts packages by default, to take advantage of the Node.js module loading semantics. Depending on what packages you install, packages end up in different places in the tree. This works great for Node, but HTML and CSS, for better or worse, generally expect things to be in one location, like /static/mypackage. There are workarounds for this to be sure, but no first-class solution yet.

Ideally, I’d like to have a solution that allows my build process to use the stuff inside node_modules to create my production build. This would mean I can automatically combine and minify my CSS dependencies inside a css/ folder in my project root, while I bundle my JavaScript dependencies inside js/. Meanwhile, node_modules should be completely invisible from a production perspective.

From what I’ve researched, there are some solutions that you can consider, many of which require an extra tool or two.

Using Tools like Browserify and webpack

Kyle Robinson Young wrote about this subject back in 2013. He said:

In order to use node modules on the browser you will need a build tool. This might bother you. If this is a deal breaker then by all means continue wasting your life copying and pasting code and arranging your script tags.

Kyle then goes on to recommend Browserify for this purpose. I had seen lots of things about Browserify before but until I started researching this subject I didn’t know exactly how it would be beneficial. Remember earlier when I mentioned that the node_modules folder makes sense for Node.js development (that is, server-side JavaScript)? Well, the Browserify website describes the tool as follows:

Browserify lets you require(‘modules’) in the browser by bundling up all of your dependencies.

So the idea is that you get the exact same benefit but you don’t have to worry about having to move stuff out of node_modules manually. The only problem here is that this doesn’t seem to be a good solution for bundling up CSS. Maybe someone with experience using Browserify can chime in and explain their process.

Another potential solution is to try webpack, another module bundler originally designed for bundling JavaScript modules. The getting started guide in their documentation has a section on adding CSS to your app. There it’s recommended to use the css-loader and style-loader webpack plugins to help with this.

Using Grunt for Simple Bundling

If something like Browserify or webpack is a little too much for you, then you could consider a simple Grunt task that bundles up your JavaScript and/or CSS modules and dependencies by means of some manual configuration.

For example, you could do something like what’s described in this Stack Overflow thread, which uses the grunt-contrib-copy plugin.

This is a pretty common solution, but I don’t think there’s an easy way to use Grunt to automatically bundle up your CSS files from installed packages, without either copying the packages from the node_modules folder or manually finding each one to configure what Grunt copies, concatenates, and minifies for production.

More on Bundling Modules and Dependencies

Installing and maintaining CSS dependencies via npm might require more work than it’s worth, but you’ll have to decide based on looking into some of the above technologies.

I might write more about this in a future post, but in the meantime here are some further resources and tools that could help:

The tl;dr Summary…

I covered a lot in this article, but a bullet list of the main ideas might help a little:

  • npm allows you to install and manage packages, usually JavaScript modules and sometimes even CSS
  • Creating a package.json file (initialized with npm init) in a project’s root will allow you to manage your dependencies and keep them up to date
  • The default install option (with no flags) helps keep package.json updated when you add, remove, or update a dependency
  • Using npm to install and manage dependencies is far superior to the manual download-and-include method
  • A tool like Browserify or webpack can help when dealing with packages strictly for front-end builds
  • Bundling CSS files in packages is challenging

Final Words

I’ve been meaning to research and brush up on my knowledge on npm for beginners for some time, so I thought it would be good to document everything I’ve learned so other front-end developers can benefit from it too. The extensive post above is what I’ve come up with.

If you have some experience in dealing with npm and how it relates to front-end development, feel free to comment and let me know if I need to be correct or improve anything. And more importantly, if you’ve managed to find a hassle-free solution to bundling front-end dependencies that includes CSS (maybe using Browserify or webpack?) I’d love to hear how you’re currently solving that problem.

36 Responses

  1. AgedLace says:

    Very helpful article. Thank you!

  2. Jade Gardner says:

    Great guide for beginners. Thanks for sharing.

  3. Scott says:

    What exactly are you having trouble with re CSS? I’ve don’t recall ever finding it problematic. I look in the package to see which CSS files I need, then concat/minify using gulp (similar to grunt).

    For Bootstrap I could use `gulp-sass` to bring in the entire lot of CSS. But for efficiency, I manually copy the bootstrap.scss file (the one containing all the @imports) to my project, rename the paths to ‘node_modules/…’ and comment out the parts I don’t need.

    • I agree, that’s basically what I expect most people do.

      But, ultimately, it would be much more efficient if you didn’t have to “look” inside the packages. Packages should just work, and you shouldn’t need to find out where the CSS files are located to point to them. npm should install them in a source folder for you automatically, or else your Grunt/Gulp task should be able to find everything without needing to tell it where they’re located.

      For a small or medium project, I don’t think it’s a big deal to do some of the manual configuration to make sure you point to the right files. But for much larger projects, I think it would help if the whole thing was more automated.

      • Scott says:

        I understand what you’re saying but I’m not sure that’s really possible. I mean, how is a package supposed to know which of its files you want to use? What if you have multiple packages in which you want to concatenate/minify one file from each? Maybe this is what bower does (or did – most people appear not to recommend it nowadays).

        • To be honest, from what I’ve seen, it’s somewhat of a flaw in npm itself in terms of the front-end. npm really isn’t built strictly for front-end development, which (as I quoted in the article) is acknowledged in the npm docs.

          It seems like there should be a better solution, a package manager just for client side JS and CSS or something like that.

        • Ameya Koshti says:

          This is exactly the problem OP is trying to state. Now you are tightly couples with the node_modules. Webpack imports does help. I think Webpack is a necessity now.

    • lennym says:

      If you are using sass, then you might find the `npm-sass` ( package useful. It allows you to seamlessly import sass from npm modules.

      Disclaimer: I wrote it.

  4. Fraser says:

    Thanks so much for this article. I’ve been using npm (specifically for gulp) for around a year, and while I’m able to get things to hang together, I’ve always felt like a lot of things never really made sense from a front end perspective. This has cleared up *a lot* of the silly questions that were always niggling at me.

    Thanks again!

    PS – I’ve just tried to post this comment like 3 times and it keeps saying “your comment appears to be spam” – what’s that all about? If it’s because I included my website in the box title “website” then that’s really silly.

  5. Erick Jones says:

    Thank you very much!

  6. Shubham Waghe says:

    Exactly my thought about the CSS, there should be something like @include(‘css’) :p Of course this looks silly but something over these lines to include CSS painlessly,..
    Good one :)

  7. Pelly says:

    Thanks for the article!
    Though a huge question remains in my head: how do I go from development to production? I mean, let’s say I develop the whole site on my machine using npm and node.
    I’m done with development and the site is now ready to go live.
    My client has a hosting which they manage themselves so I can’t install node and npm on their server, how am I supposed to make node.js work with the website I built? Shouldn’t I then go and include all the files manually anyway? Isn’t there a way to ‘compile’ npm before going live so that it converts its code to normal script src tags?

    Also isn’t node.js pushing the front end dev into something that should be more back-end related?

    Sorry if these questions might be silly to you, but I’m really confused :)

    • Hi Pelly,

      If you’re developing a website that uses Node.js on the back-end (like using PHP), then that’s a completely different story. I’m not sure if that’s what you meant though. My article is dealing with front-end code that uses npm as a package manager, which will not affect anything about pushing to production.

      When you push to production, you’re just uploading the files that make the site work. So you might have a bunch of .html pages, along with CSS and JS files. The node_modules folder is just for packaging things up, for updating the packages you use, and for separating your JS into modules. But when you push to production, you’re first going to use something like Grunt to concatenate and minify those files, then you’re going to upload a single JS file and CSS file.

      But like I said, if you’re talking about developing the backend with Node.js, then that’s something completely different that this article won’t help you with.

  8. Raul Mercado says:

    Great article. It’s true that npm is mainly used for the server side. If you want to have something like that you can use a package manager for the front-end which is bower (, the commands for this tool are very similar to npm so the learning curve will be minimal.


    • Dan Kelly says:

      Considering that bower themselves are recommending that you use Yarn / Webpack rather than bower, probably not the best suggestion”

  9. Oleg Fisun says:

    Very interesting and helpful article. Thanks

  10. konrados says:

    Hi Louis. Thanks for the article, this is exactly what I needed – a npm tutorial from the frontend point of view. I had the same questions as you.

    You should write a similar about webpack now :)

    BTW: regarding npm install –save – I think the –save is not needed anymore (maybe it was in the past):

    -P, –save-prod: Package will appear in your dependencies. This is the default unless -D or -O are present.

    Thanks again!

    • Glad you enjoyed it!

      Yes, it looks like you’re right about “–save”… I’ll have to update the article accordingly.

      As for webpack, I haven’t really touched it yet, but I have been meaning to look into it. :)

  11. Yonas says:

    I have a lot of experience with npm, but sometimes concepts get lost in my head and I have to revisit the basics. I’m so happy I came across this writeup. Thanks so much for taking the time to put it together: it is fantastic.

  12. Ayush Gupta says:

    This a great write-up for a beginner to understand npm and it’s working architecture. Thanks for sharing this.

  13. Driss says:

    I’m using a package called npm copyfiles to copy node_modules file to my source folder.
    I think this package is an alternative to grunt & gulp!

  14. Qasim says:

    What if I don’t want to package and concatenate all my files on very webpage on my site — some things are only used in some places.

    I wonder how I’d go about handling that…

  15. Wolfgang says:

    A really excellent article – thanks for sharing your knowledge and explaining it in such a good way – not a skill everybody has in this domain! I think adding some information on bundling with webpack and what npm run dev vs npm run build does would complete the article.
    PS: Please correct the link to npm github repo (now it is

    • Thanks for the link correction! It’s now fixed.

      And yeah, I’ve been meaning to do something on webpack at some point but I’d have to do the research on it as I’m not familiar with webpack.

  16. David Ryan says:

    Very informative guide for beginners. Thanks for sharing it.

  17. Macandro says:

    Thank you so much for sharing beginners guide for front-end developers, this article is very useful for us.

  18. Evan G Grantham-Brown says:

    This was incredibly helpful, thank you! Now I just have to go figure out webpack…

  19. Joachim Rosenberger says:

    Great article, but should be updated, e.g., –save is now default.

    • Thanks for the heads up! I actually had added a note explaining that, but the rest of the article needed to be updated, so I’ve fixed it. I might have to fine tune the wording a bit but I think it should be fine now.

  20. Abram Abram says:

    I didn’t have any expectations concerning that title, but the more I was astonished. The author did a great job. I spent a few minutes reading and checking the facts. Everything is very clear and understandable. I like posts that fill in your knowledge gaps. This one is of the sort.

  21. Thank you! NPM has never been my favorite package manager, but building a website without it is also not great. This answered all of my questions and will make my job easier!

  22. Laxminarayan Kamath says:

    When I came back into Front end developing after a decade, all the use of mixture of technologies from front end and backend almost made me go crazy. It was like .. “I know this , but I don’t know what it is doing here. How do people even manage this craziness??”

    With some exaggeration, it was like coming across methods to solve nth polynomial equations in a recipe book for pasta.

    This article finally laid it out straight for me. God bless.

  23. Fenix says:

    Lol, “package is a bit of a buzzword” :-D
    Not in backend terminology where “plugin” is usually not used. And npm is more related/developed for backend ;)

Leave a Reply

Comment Rules: Please use a real name or alias. Keywords are not allowed in the "name" field and deep URLs are not allowed in the "Website" field. If you use keywords or deep URLs, your comment or URL will be removed. No foul language, please. Thank you for cooperating.

Markdown in use! Use `backticks` for inline code snippets and triple backticks at start and end for code blocks. You can also indent a code block four spaces. And no need to escape HTML, just type it correctly but make sure it's inside code delimeters (backticks or triple backticks).