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

The Issue

npm run build is a command that is quite familiar to JavaScript developers when preparing to release a new version of an application. Simply put, npm run build performs the task of converting the code in the project into executable code in the browser or Node.js.

But why is the build step necessary? What is the essence of build? Do all JavaScript/Node.js projects need to build? Hopefully, readers will find the answers in the article below.

NPM Scripts

package.json is an important file present in most JavaScript/Node.js projects. Its function is to store project information as well as configurations and commands that will be used. For example, package.json keeps track of all the libraries so that whenever dependencies need to be installed, just run npm install.

scripts is a property in package.json that holds values like the ones below:

{  
  "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 type npm run build, the actual command executed underneath is vue-tsc --noEmit && vite build. In other words, build is just a placeholder for the actual command you want to run. If I decide I don't like build, I can change its name to release, and it won't be a problem. To run it, just type npm run release. At this point, npm run release is just like npm run build before.

scripts are designed to hide the complexity of remembering the commands that will be used in the project. In the above example, which is easier to remember: npm run build or vue-tsc --noEmit && vite build? In a project, there can be not just one command but sometimes up to dozens. They can also be interconnected, meaning one command can be the sum of many other commands. That’s when scripts really shines as a perfect place to store these values.

Looking at the build command above, it combines tsc and vite build. Creating multiple commands at the granular level allows for reuse. Naming them gives them meaningful recall. Imagine opening package.json in any project and seeing build in scripts; it surely indicates a command related to preparing for a new version release of the application.

The Complexity of Browsers/Node.js

JavaScript itself carries much complexity; sometimes you can't fathom why typeof null == 'object' and countless other absurdities when working with it. To explain, there are many reasons; one of them is the fragmentation of JavaScript. Unlike other languages, where you just need to download and install the setup to use, once you've written the code, deploying the application on the server requires using the exact version previously installed to ensure success.

JavaScript, on the other hand, leaves it to the browser to decide whether to run JavaScript code. And there are many types of browsers, not all of which adhere to JavaScript's rules. When a new version of JavaScript is released, the browser must subsequently issue an update to support it. What happens if users refuse to update their browsers, or if a browser is reluctant to keep up with the latest JavaScript features? In other words, a piece of JavaScript code that runs on one browser may not run on another. This creates a headache for JavaScript developers trying to solve the problem of "maximizing user support".

Node.js reduces fragmentation more because it only uses Chrome's V8. Using Node.js means you have to use V8. Moreover, Node.js runs on the server side, so it doesn't face the same challenges as browsers.

In reality, not all users have the latest browser versions. Not everyone uses Chrome or Firefox... Developers always worry about whether the code being written will be compatible with all users. The idea of tools that allow "write once - run everywhere" emerged from this.

You may have heard of babel.js, a library that converts newer JavaScript code into code that most browsers can execute. Simply put, if you want to use the latest JavaScript syntax while still ensuring compatibility with older browsers, babel.js helps achieve that. All you need to do is install babel, write the code, and then use it to convert the code you just wrote. That's when the build command comes into play. The build command may include commands using babel, as shown in the example below.

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

With the emergence of many frameworks that support building applications based on reactions like Angular, React, Vue... even more code conversion tools have appeared. Essentially, these frameworks hide the complexities of development and, until release, use tools like webpack, rollup, vite... This helps application developers focus more on writing code rather than worrying about whether their application will run well on IE8.

Do all applications need to build?

The answer is no. As I mentioned, build is just a placeholder for a complex command. It also carries a mnemonic meaning. build often appears in projects that use tools to support converting simple code into complex code, such as babel, or packaging tools like webpack, rollup...

If you are developing a simple JavaScript application without using the above tools, it is clear that you do not need to go through a build step. The browser or Node.js can run the code you wrote.

Conclusion

package.json is a file that contains parameters and configurations for JavaScript/Node.js projects. scripts is a property that contains the commands that run each time npm run is used. scripts helps hide the complexity of commands and carries mnemonic significance; build encompasses those factors.

Therefore, projects that use code conversion tools like babel, webpack... are the only ones that need build. Conversely, if developing a simple project, the build step is not necessary.