Front-End Development Without node_modules
Once upon a time, we could simply put an HTML and a script file into an FTP server, quickly have a working website and call it a day.
Today, we have to jump through many hoops just to get the right things in the right places. Suppose Alice wants to spend her weekend making a simple to-do app or whatever little idea she enjoys. First, she has to install a big heap of 10k npm packages files. Then she spends a few hours searching how to get this week’s js bundler working with the latest typescript with the latest trending UI framework. And a lot frustrating when things don’t work or those articles have just outdated. Once she has actually started building the first feature for her little fun app, the weekend has mostly gone!
But things are changing…
1. A little backstory: CommonJS and ES Module
Working with NodeJS, we all get familiar with CommonJS, the standard (read: legacy) way for NodeJS to load dependency code. After installing a module, for example,
lodash, we can load it into our code by using
require('lodash'). This is how NodeJS handles dependency code from the beginning:
In NodeJS, to enable ES Module, we have two choices: use .mjs extension or set
"type": "module" in package.json. And while most development tools understand ES Module, there are still many incompatibles. For example, TypeScript still does not support outputting to .mjs files. Or Vercel does not work with ES Module. So some transpilers and workarounds are still required. Hopefully, the situation will change soon™.
Many packages in NodeJS are already shipped with ES Module files. But many packages are not. At the time of this writing, in the top 10 depended packages on npm, only tslib supports ES Module file by including
"exports" in package.json. Many other top packages still don't ship ES Module: lodash, moment, react, request, axios, chalk, commander, express... It's actually not a problem for NodeJS, because NodeJS allows using import to work with both ES Module and CommonJS format.
But browsers don’t have that privilege. What if you want to import your favorite node module in the browser? Well, you have to be lucky. At the time of this writing, the recommended way for React to get started in the browser is to include the UMD version in
<script> tag, and use the global variable
No ES Module for Alice.
Skypack is a wonderful CDN service that transpiles node packages to be able to work well in the browser. It’s backed by Snowpack team. Simply put the package name@version after cdn.skypack.dev and you are ready to go:
It just works! Of course, you may ask, there is “lodash-es” that we can import. But many packages don’t have their doppelgängers. Or they are not frequently updated. Here, skypack.dev comes to the rescue.
It still has some problems, though. For unclear reasons, some versions did not work. When visiting cdn.skypack.dev/react@16, the React version 17 is served instead. But the future is bright. Alice can now start working right on her app without spending most of her weekend configuring this week’s js bundler …
Side note: I also put my own version at espkg.vercel.app/react@16. You can use espkg.vercel.app as an alternative until Skypack fixes the problem. Other packages also work, for example, espkg.vercel.app/lodash@4 (give it a little time for building, then the response will be cached by Vercel).
Okay, I lied, a bit. TypeScript won’t work directly in the browser. You still need more work. Here come the real power of Snowpack: minimal config and remote packages. You don’t even have to install node_modules to start working with your little fun app. Simply run 2 setup commands:
yarn global add snowpack
This will give you an empty skeleton snowpack.config.js. Then add the single line config
source: 'remote' under
That’s all! Now run
snowpack dev and start adding your index.html and myscript.ts (yes, it's TypeScript):
It just works! 🎉 Look ma, no node_modules! No package.json! We even got TypeScript and hot-reload for free. Yay!
Oh, but Alice wants to use less. No worry, just a single line config… I swear! She could add a file mystyle.less and one more line for snowpack.config.js. Everything will be okay. Well, this time she must remember to run
yarn add snowpack-plugin-less! Only this time...
Thank you for reading! And don’t forget my little page espkg.vercel.app.
Previously published at olvrng.github.io.