Using npm modules

I recently got my first job as a solo front-end developer. So far I have always used simple script tags. I am using enough polyfills and libraries that it might be useful to use npm instead of downloading files and writing script tags. (I am looking to use NPM only for front-end stuff as I do not use node.js for a backend)
So far I have got as far as: download Node, download NPM, cd into project folder, npm init to create package.json, npm install whateverpackage.
How do I use the package? Do i have to import it? So far it feels like to solve a minor problem I am creating a far more complex problem and workflow.

And if it changes anything - I don’t need things to act like ‘modules’ - use strict by default, importing only certain variables, etc, just looking for the simplest to use polyfills and libraries.

1 Like

So far it feels like to solve a minor problem I am creating a far more complex problem and workflow.

It can feel like that at first, when you’re first jumping into it. But once you get over the initial learning curve, you’ll find that you’re far more productive than before. You can do more in less time and end up with a more refined and efficient end product.

For frontend work, you’re going to need to import them, but to do that, you’re going to need to compile your scripts before shipping using Webpack or something similar. If you want to import your own files, and you should, then you will need to build them as an exportable module. The end product is a single compiled JS file, which is faster to download than many files if you’re not using HTTP2.

Check out the Webpack Getting Started Tutorial tutorial. I’ve found that a lot of people seem to struggle with webpack at first, but it’s really only as complicated as you make it out to be. Once you wrap your head around what it’s doing, it’s actually incredibly simple. But it’s very powerful and I think some people try to jump into that extra power too soon and confuse themselves.

You will need to reference your compiled output JS file in your HTML, instead of many different files. At the bottom of that tutorial is a description of “watch mode”, which is invaluable.

Once you’re comfortable with Webpack and your workflow allows for it, you can look into webpack-dev-server, which makes the whole pain of frontend development go away once you get it set up. But, I don’t suggest that till you’re absolutely comfortable with basic webpack functionality. Same goes for Babel, if you end up running into that.

If you want to write your own modules, then you will probably need to change up the pattern of the way you’re currently writing your JS. Sitepoint has some good article on importing and exporting.

Like I said, there is a learning curve here. But I really suggest taking the dive into it. You will come out the other side a better, faster, and more productive developer.

Good luck. When you have more questions, I’ll do my best to help


In addition to the good information mawburn gave in his post, I just wanted to point out that SitePoint recently published an article that you might find useful: The Anatomy of a Modern JavaScript Application. It gives an overview of all the main concepts and tools commonly used in front-end development these days.


Also, this post from the other day puts the added complexity into perspective.

The page looks gross, but this is the creator and CTO of npm.

Thanks for the useful tips Mawburn. I’ve been experimenting with webpack. One thing I don’t understand: why is it that when I import a function or variable or object into another module I can use it, but when I am in the console of the browser those functions and variables and objects are not there for me?
For examples, in my file this code works to make an alert

import {name, age, description} from './module1.js'; 
alert(name + age + description);

whereas in the browser console they are all undefined.

Hey there!
It is tough to get into this topic, especially when you were used to using script tags. I’ve been there too. I got used to use webpack because it allows you a lot more than just using npm modules.

The syntax you use there is not implemented in the latest browsers yet. Chrome 60 will start to support import natively. What you do with Webpack (or Babel more specificially) is to transpile modern javascript features to use them in (almost) any browser version. A little like the polyfills you already know. It is a little more complex to polyfill entire new syntax features, which is why webpack is bundling and transpiling this code for you.

Also, webpack creates your own scope for you, so you avoid littering the global scope with variables. This is considered a best practice. If you want to access variables in global scope, assign them to window. E.g.: window.age = age.
But you should do that for debugging purposes only - depending on your usecase of course.
For debugging in Chrome, you can console.log() a variable and the dev-tools console will point you to the file and line, so you can place a debugging breakpoint there. This is usually a lot more effective than juggling with global variables. See the docs how to use the debugger:

What makes webpack so much more comfortable to work with, instead of using script and link tags, everytime you need to add a new polyfill or library, is that you can use import and a lot of other modern features that ease development.

Hope you are having a good time getting started with that technology.
Happy coding.


Hi Martin. I should have mentioned that I’ve started trying out using Webpack with Babel, so the syntax I’ve used in my example should work. I’m a little freaked out with how much code Webpack and Babel spits out.
All I imported was debounce from Lodash but now my code is gigantic :frowning:

I’m a little freaked out with how much code Webpack and Babel spits out.

There is some extra boilerplate that Webpack throws in there to help with scoping. The initial is about 300 lines or so, but doesn’t grow a whole lot when you start adding more. Overall doesn’t add that much. You can use Webpack to uglify your JS for production. Which if you weren’t doing before, should end up saving you a few bytes.

It depends how you import debounce – if you do so like

import { debounce } from 'lodash'

it will still include the entire lodash library in your bundle. If you only want to include the parts you need, you can do so like

import debounce from 'lodash/debounce'

and you’ll only get the minimally necessary parts. Another option is tree shaking, which will automatically detect and exclude the parts you don’t need.

PS: Keep in mind that when you’re including your dependencies in script tags, you don’t have such possibilities at all – you’re always pulling the entire library then. ;-)


This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.