Discussing the npm run build command – why is it necessary to build?

The Issue

The npm run build command is not unfamiliar to JavaScript developers when preparing to release a new version of their application. In simple terms, npm run build converts the project's code into executable code that can run in the browser or Node.js.

But why is there a need for the build step? What is the essence of building? Do all JavaScript/Node.js projects need to be built? Hopefully, readers will find the answers in the following article.

npm script

package.json is a file present in JavaScript or Node.js projects. Its purpose is to store project information, configuration, and instructions for the project to function. For example, in package.json, all the npm dependencies are stored so that whenever there is a need to install dependencies, one only needs to run npm install.

"scripts" is an attribute in package.json that holds values like the following:

{
  "scripts": {
    "dev": "vite",  
    "tsc": "vue-tsc --noEmit",  
    "build": "npm run tsc && vite build",  
    "build-dev": "vue-tsc --noEmit && vite build --mode development",  
    "serve": "vite preview"
  }
}

When we run npm run build, behind the scenes, the actual command being executed is vue-tsc --noEmit && vite build. In other words, "build" is just a "representative name" for the command you actually want to run. If you don't like "build," you can rename it to "release" without any issues. If you want to run it, simply type npm run release, and that's done. npm run release is now equivalent to the previously mentioned npm run build.

"scripts" exist to abstract the complexity of remembering project commands. In the example above, which is easier to remember, npm run build or vue-tsc --noEmit && vite build? Furthermore, in a project, there may be not just one command but sometimes many, even dozens. They might be interconnected, meaning one command is composed of multiple other commands put together.

Look at the build command line; it combines tsc and vite build. Creating multiple scripts with shared molecules allows for reusability. Naming them also adds meaning as a reminder. This means that for any project, if you open package.json and see "build" in "scripts," it most likely represents the command for preparing to release a new version of the application.

The Complexity of Browsers/Node.js

JavaScript was born with many complexities, sometimes making it difficult to understand why typeof null == 'object' and countless other illogical things when working with it. There are many reasons to explain this, one of them being the fragmentation of JavaScript.

With other languages, you simply download and install the necessary version to use it. Once developed, deploying the app to a server only requires using the correct installed version, and everything works. But with JavaScript, it's the opposite. Permission to run JavaScript is contingent upon the browser. And there are many browsers, not all of which adhere to JavaScript rules. In other words, JavaScript code that runs well on one browser is not necessarily guaranteed to run on another.

Node.js reduces fragmentation to some extent because it uses Chrome's V8 engine. Using Node.js means using V8. Another positive aspect is that Chrome is currently the "king" of browsers, so in response to that, it is always the first to update the ECMAScript standards. Those updates always bring new features.

Looking at reality, not every user has the latest version of a browser. Not everyone uses Chrome or Firefox... so worrying about whether the code you're about to write will run on all browsers or not is a legitimate concern. From this point, the idea of tools that support writing code once and "transpiling" it for all browsers emerged.

You may have heard of Babel.js, which is a library that transpiles newer JavaScript code into older code that most browsers, both old and new, can execute. In simple terms, if you want to use the latest JavaScript syntax and still have it work on older or different browsers, Babel.js helps you achieve that. You need to install Babel.js, write code, and then use it to transpile the code you just wrote. That's when the "build" command comes into play. The build command could contain a command that utilizes Babel. Instead of having to type a complex command, we only need to do npm run build.

{
  "scripts": {
    "build": "babel src -d lib"
  }
}

Today, with the emergence of many React-based frameworks like Angular, React, Vue, the prominence of build tools has increased. Essentially, frameworks hide the complexity during development and until release using build tools like webpack, rollup, vite... This allows application developers to focus more on coding rather than "inventing" project structure.

Do all applications need to be built?

The answer is no. As I mentioned, "build" is just a "representative name" for a complex command, and it also carries a meaningful reminder. "Build" typically appears in projects that use build tools like Babel, webpack, rollup...

If you are developing a basic pure JavaScript application without using such tools, then obviously you don't need to "build." Browsers or Node.js can execute the code you write.

Conclusion

package.json is a file that contains information and configurations for JavaScript/Node.js projects. "scripts" is an attribute that holds values and corresponding commands to be executed when using npm run. "scripts" helps abstract away the complexity of commands and carry meaningful reminders. "Build" also carries that meaning.

Therefore, projects that use build tools like Babel, webpack, etc., require a "build" step. For other cases, if you are developing a pure JavaScript project that browsers can understand, there is no need for the build step.