This blog post covers a technical challenge involved in preparing a JavaScript project for release that is often forgotten about until the very last moment. The challenge is building (compiling) this project correctly, depending on what is actually being released - an application or a library.
Even if you already have experience building and deploying JS apps, you might be surprised to find out that when it comes to libraries not only is the release workflow different - deploying an application to a server versus publishing a new version to a registry - but the approaches and even tools you would use to build the project differ also. I was certainly surprised a few years back when I realized that I had to ditch webpack and move to rollup just because I wanted to build a library!
I could conjure up an academic definition for both of these terms, but the essential difference is easy to describe and understand - An application is an executable piece of software for users to use and interact with directly, while a library is a non-executable piece of software that your users don’t interact with, but other libraries and/or applications rely on. Applications are used by users, but libraries are used by applications to add extra features and behaviors without the developers having to code them themselves.
Here’s an example of both:
An application could be the Node.js backend for your cat blog that is running on a server somewhere and processing all of the incoming requests. During development you wouldn’t want to code all of the low-level logic necessary to handle and respond to web requests, so you would probably use a library that does all of that for you - Express.js, for example.
<aside> 💡 Essentially libraries are kind of like reusable building blocks of applications.
</aside>
Let’s start off with the most common option of the two - building an application. Unlike a library, an application needs to be executable in chosen target environments.
If the app is a server backend preparing it for execution is pretty simple because there’s usually only a single environment the server needs to run in - your chosen server (e.g., a Ubuntu machine or maybe a specific kind of Docker container). Additionally, you can get away with needing no compilation or build steps, because you can just run a Node.js script directly. That said, if you want to write in TypeScript or use new ECMAScript features not supported by your Node version, you’ll need a build step.
If you’re building a frontend app, however, let’s say a Single Page Application, preparation gets more complicated, because this client-side app needs to be able to run on multiple different versions of multiple different browsers. Besides that, there’s also the fact that you need to compile your application, as it is highly unlikely that your source code can be directly ran as-is inside a browser.
Compiling a JS app for the web is pretty much the most common JS compilation use case so the good news is that there are many tools and approaches that will help you get this done. Often you don’t even need to think about it, because a framework that you’re using might have a stable compilation config baked into it. If you’ve ever used something like Next.js or Nuxt.js, you’ll know that the framework comes with predefined build and run commands that compile everything correctly without your involvement.
Personally, I’ve used webpack a lot and even though there are more performant options nowadays I still suggest getting to know it because unlike some other build tools it is very versatile, very well supported, and you can configure it to work pretty much any way you want to. rollup is another good one that might not be as popular, but also allows for deep configuration and has a ton of community support through custom plugins and loaders. Vite is an interesting one that has appeared on the scene fairly recently. It may not be as popular and thus have as much support as the other ones, but it has a nice trick under its sleeve - It compiles development builds using esbuild, and production builds using rollup. This enables developers to have greatly increased build speeds when working on the app on their local machines.
Whatever tool you’re using, the idea is the same - to take all of your source code and assets and bundle it all up in an application that can be ran in your chosen target environment/-s.
