Develop Reference

Is webpack a suitable tool to bundle a Node.js backend code? [duplicate]

I was just wondering, I started using Webpack for a new project and so far it's working fine. I almost would say I like it better than Grunt, which I used before. But now I'm quite confused how and or I should use it with my Express back-end?
See, I'm creating one app with a front-end (ReactJS) and a back-end (ExpressJS). The app will be published on Heroku. Now it seems like I should use Webpack with ExpressJS as well to get the app up and running with one single command (front-end and back-end).
But the guy who wrote this blogpost http://jlongster.com/Backend-Apps-with-Webpack--Part-I seems to use Webpack for bundling all back-end js files together, which is in my opinion really not necessary. Why should I bundle my back-end files? I think I just want to run the back-end, watch my back-end files for changes and use the rest of Webpack's power just for the front-end.
How do you guys bundle the front-end but at the same time run the back-end nodejs part? Or is there any good reason to bundle back-end files with Webpack?

Why to use webpack on node backend
If we are talking about react and node app you can build isomorphic react app. And if you are using import ES6 Modules in react app on client side it's ok - they are bundled by webpack on the client side.
But the problem is on server when you are using the same react modules since node doesn't support ES6 Modules. You can use require('babel/register'); in node server side but it transipile code in runtime - it's not effective. The most common way to solve this problem is pack backend by webpack (you don't need all code to be transpile by webpack - only problematic, like react stuff in this example).
The same goes with JSX.
Bundling frontend and backend at the same time
Your webpack config can have to configs in array: one for frontend and second for backend:
webpack.config.js
const common = {
module: {
loaders: [ /* common loaders */ ]
},
plugins: [ /* common plugins */ ],
resolve: {
extensions: ['', '.js', '.jsx'] // common extensions
}
// other plugins, postcss config etc. common for frontend and backend
};
const frontend = {
entry: [
'frontend.js'
],
output: {
filename: 'frontend-output.js'
}
// other loaders, plugins etc. specific for frontend
};
const backend = {
entry: [
'backend.js'
],
output: {
filename: 'backend-output.js'
},
target: 'node',
externals: // specify for example node_modules to be not bundled
// other loaders, plugins etc. specific for backend
};
module.exports = [
Object.assign({} , common, frontend),
Object.assign({} , common, backend)
];
If you start this config with webpack --watch it will in parallel build your two files. When you edit frontend specific code only frontend-output.js will be generated, the same is for backend-output.js. The best part is when you edit isomorphic react part - webpack will build both files at once.
You can find in this tutorial explanation when to use webpack for node (in chapter 4).

This is my second update to this answer, which is beyond outdated by now.
If you need full a stack web framework in 2023, I'd recommend nextjs (which is built on top of react). No need to go around setting up anything, it just works out of the box, and is full stack.
On the other hand, if you need to compile your nodejs project written in typescript (which you should use as much as you can for js projects), I would use tsup-node.
You don't need to be a genius to imagine that in 3-5 years I'll come back to this and say this is really outdated, welcome to javascript.
This answer is outdated by now since node now has better support for ES modules
There's only a couple of aspects I can redeem the need to use webpack for backend code.
ES modules (import)
import has only experimental support in node (at least since node 8 up to 15). But you don't need to use webpack for them work in node.
Just use esm which is very lightweight and has no build step.
Linting
Just use eslint, no need to use webpack.
Hot reloading/restart
You can use nodemon for this. It's not hot reloading but I think it's way easier to deal with.
I wished I could refer to a more lightweight project than nodemon, but it does do the trick.
The blog post you shared (which is dated by now) uses webpack for having hot reloading. I think that's an overkill, opens a can of worms because now you have to deal with webpack config issues and hot reloading can also lead to unexpected behaviour.
The benefits we get from using tools like webpack on the frontend don't really translate to backend.
The other reasons why we bundle files in frontend is so browsers can download them in an optimal way, in optimal chunks, with cache busting, minified. There's no need for any of these in the backend.
Old (and terrible, but maybe useful) answer
You can use webpack-node-externals, from the readme:
npm install webpack-node-externals --save-dev
In your webpack.config.js:
var nodeExternals = require('webpack-node-externals');
module.exports = {
...
target: 'node', // in order to ignore built-in modules like path, fs, etc.
externals: [nodeExternals()], // in order to ignore all modules in node_modules folder
...
};

to use Webpack for bundling all back-end js files together, which is in my opinion really not necessary.
I think you are absolutely right. It's not necessary at all. I've been researching on this topic for a while. I've asked lots of questions on this topic, and up to this day, I haven't found yet a single "real" reason for one to use webpack on a Node.js back-end.
I'm not saying you can't or shouldn't set up a webpack-dev-server to develop your back-end code locally. But you definitely don't need to bundle your backend code on your build process.
webpack bundles are meant for the browser. Take a look at its official docs: Why webpack?. Historically, browsers never had a built-in module system, that's the reason why you need webpack. It basically implements a module system on the browser. On the other hand, Node.js has a built-it module system out of the box.
And I do re-use all of my front-end code for SSR on my server. The very same front-end files are run on my server as-is without any bundling (they are just transpiled, but the folder structured and number of files is the same). Of course I bundle it to run on the browser, but that's all.
To run on your Node.js server, simply transpile it with babel, without webpack.
Just use ["#babel/preset-env", { targets: { node: "12" }}], on your babel config. Choose the Node version of your backend environment.
backend
dist_app // BABEL TRANSPILED CODE FROM frontend/src
dist_service // BABEL TRANSPILED CODE FROM backend/src
src
index.tsx
frontend
src
App.tsx
public // WEBPACK BUNDLED CODE FROM frontend/src
You can perfectly render your frontend code on the server, by doing:
backend/src/index.tsx
import { renderToString } from "react-dom/server";
import App from "../dist_app/App";
const html = renderToString(<App/>);
This would be considered isomorphic, I guess.
If you use path aliases on your code, you should use babel-plugin-module-resolver.

Combine, Minify, and convert to ES5 with WebPack and Babel

I have a project that works perfect and was written in TS, I had to convert it to plain JS and it works for the most part. The issue where I am struggling is removing the default WebPack loader after the files have been combined and minified, WebPack includes a loader to the final output even thought I do not need a loader since all the files are combined into one large file.
+ filea.js
+ fileb.js
+ filec.js
+ filed.js
-> output bundle.js
I have read a few articles/posts that recommend manually creating a config file providing the name of each of the files that will combined and minified, this may work OK but the problem is that the project I am working on is broken into small chunks (modules) so that tools such WebPack can be smart enough and know when a file should be added as a dependency in the final output.
I know we can combine and minify multiple individual JS files but when it comes to exporting a single file it seems like the task is trivial With TS but in the vanilla JS world there is little or no information about the subject.

I don't understand something, do you want to have one big file or small individual modules (chunks)?
An example of small modules:
module.exports = {  
entry: {    
app: './src/app.js',
admin: './src/admin.js',
contact: './src/contact.js'  
}
};
Another method is one main module and it contains all smaller modules.
module.exports = {  
entry: {    
app: './src/app.js'  
}
};
You can also use something like lazy loading. Then the modules (chunks) will be dynamically loaded only when needed. lazy-loading
Here is an example of using several entries webpack-boilerplate.

Sounds like you have a project with several JS files and you want to use webpack to bundle all of them and minify the result.
Webpack was built for this.
You'll need to add a build step in your package.json like this:
"scripts": {
"build": "webpack --config prod.config.js"
}
Then you'll need to create a webpack.config.js with a module.exports block that has an entry point and rules to include in your project. The following should be a minimal setup that can get your started:
const path = require('path');
module.exports = {
entry: "./your/path/to/src",
output: {
path: path.resolve(__dirname, "dist"),
filename: "bundle.js"
},
module: {},
plugins: [
new MinifyPlugin(minifyOpts, pluginOpts)
]
}
You can add modules that perform additional code transpilation for files that matcha a certain regex. You can also use a plugin to perform minification such as babel-minify-webpack-plugin as documented here https://webpack.js.org/plugins/babel-minify-webpack-plugin/. (Note you will need to add this dependency.)
The full webpack configuration can be found here: https://webpack.js.org/configuration/

Webpack to "ignore" some entrypoints

I'm using Webpack to build my front end components.
I have some React components which need classic webpack bundling, though I also have some vanilla JS files.
Those latter files are independent, so they won't get imported from React files. From my understanding, they need to be defined as entrypoints, so that Webpack reads and processes them. So far, so good.
The trouble is that I'd like Webpack to load them with Babel, and that's all, only give me back the JS file processed through Babel, I'm not interested in a bundle for these files.
Is it possible to do that? Only get the result of the babel loader, and not produce a bundle for some entrypoints?
Maybe I shouldn't use Webpack at all for these files?
Or maybe I should just set these bundles as 'library' so that I can reach them from the HTML pages?
What do you think guys?
Thanks by advance ;)

depends on how easy it is to find these files. I have a project that has similar requirement. What I have done is:
1/ put the vanilla js file in third_party/lib/
2/ import/require them in my current project
3/ set up my webpack.config.js as follows:
module.export = {
module: {
rules: [{
test : /.js$/,
exclude : /node_modules|third_party/,
loaders : ['babel-loader' /* other loaders? */],
},{
test : /third_party.*?\.js$/,
use: [{
loader : 'babel-loader' // or other loaders
},{
loader: 'file-loader'
options: {
name : '[path][name].[ext]',
outputPath : 'dist/third_party'
}
}]
}]
}
}
oh, you will need to npm i --save-dev file-loader
edit: I should clarify that this will bundle the vanilla js file as separate files to your main bundle, so you will have to import them by script tags yourself in your html file. (or if they were worker files, called by your script)

How to bundle a library with webpack?

I want to create a frontend library.
Therefore I want to use webpack. I especially like the css and image loader.
However I can only require non-JS files if I am using webpack.
Because I am building a library, I cannot garanty that the user of my library will too.
Is there I way to bundle everything into a UMD module to publish it?
I tried using multiple entry points, however I cannot require the module then.

You can find good guide for creating libraries in Webpack 2.0 documentation site. That's why I use ver 2 syntax in webpack.config.js for this example.
Here is a Github repo with an example library.
It builds all files from src/ (js, png and css) into one JS bundle which could be simply required as an umd module.
for that we need to specify the follow settings in webpack.config.js:
output: {
path: './dist',
filename: 'libpack.js',
library: 'libpack',
libraryTarget:'umd'
},
and package.json should have:
"main": "dist/libpack.js",
Note that you need to use appropriate loaders to pack everything in one file. e.g. base64-image-loader instead of file-loader

The comment written by #OlegPro is very helpful. I suggest every one to read this article for explanation of how these stuff work
http://krasimirtsonev.com/blog/article/javascript-library-starter-using-webpack-es6
You need the following for sure if you want to be able to import the bundle file in your project
output: {
path: path.resolve(__dirname, myLibrary),
filename: 'bundle.js',
library: "myLibrary", // Important
libraryTarget: 'umd', // Important
umdNamedDefine: true // Important
},

react js with browserify

I start to learn react js and they say on the react website "We recommend using React with a CommonJS module system like browserify"
So I used browserify with a simple hello world react component. Finally it produces an output file bundle.js of 651 ko (just for a simple hello world).
With this file bundle.js, I no longer have to include the scripts react.js and react-dom.js in my webpage, so I concluded that the file bundle.js includes my component and the react library.
But if I creates many components, I will have some javascript files and after the browserify transformation, each output files will be big because each files contains the react library. it will produce only one output file.
So I don't understand why they recommend to use browserify rather than just include react.js and react-dom.js library into my webpage and also my components js files after a babel transformation?

For development it is better not to minify. You apply minify when you go to production. For example with gulp;
gulp.task('appjs', function(){
browserify({ debug: true })
.transform(babel.configure({stage: 0}))
.require(source.appjs, { entry: true })
.bundle()
.pipe(vsource('app.min.js'))
.pipe(gulp.dest('./ui-dist'));
});
gulp.task('buildapp', function(){
browserify({ debug: false })
.transform(babel)
.require(source.appjs, { entry: true })
.bundle()
.pipe(vsource('app.min.js'))
.pipe(vbuffer())
.pipe(uglify())
.pipe(gulp.dest('./ui-dist'));
});

I think your question is about the size of the bundle file (the resulted file of browserify build), you worry about the time it will take when loaded on the page. This is some really important things you should know :
1. you don't have to include all your files in one bundle : you can generate multiple bundles. For example, you can configure browserify to create one bundle for your vendor files, and one or multiple bundles for your components.
in Dev mode, you don't have to minify your bundle,
For prod, you should generate your bundle using the react prod mode and minification.
To achieve point 1 (multiple bundles), here is an example with grunt browserify plugin.
var jsFiles = {
jsSrcFiles: './src/main/js/vs/**/*.js*', // my js and jsx source files
jsLibs: [
// vendor libs that I want to put in separate bundle
'react/addons',
...
]
};
...
browserify: {
app: {
options: {
transform: ['reactify'],
extensions: ['.jsx'],
// Here is where I tell browserify not to bundle vendor files with my source files
external: jsFiles.jsLibs
},
src: [jsFiles.jsSrcFiles],
dest: buildParams.js + '/vs_app.js'
},
// here is where I build vendor files in separate bundle named vendor.js
vendor: {
src: ['.'],
dest: buildParams.js + '/vendor.js',
options: {
alias: jsFiles.jsLibs
}
}
}...
Browserify is a great tool when it comes to small projects, when your project becomes more complex, browserify config tends to be very complex. In order to have more control of your built bundles, I recommend to use webpack, which is also a tool that facebook recommends. It allows easy bundling customization...