后端的网络包?

我只是想知道,我开始使用 Webpack 的一个新项目,到目前为止工作良好。我几乎要说我喜欢它胜过我以前用过的 Grunt。但是现在我很困惑,我应该如何和我的 Express 后端使用它?

看,我正在创建一个具有前端(ReactJS)和后端(ExpressJS)的应用程序。该应用程序将在 Heroku 上发布。现在看起来我应该使用带 ExpressJS 的 Webpack 来启动应用程序并使用一个命令(前端和后端)运行它。

但是写这篇博客文章 http://jlongster.com/Backend-Apps-with-Webpack--Part-I的人似乎使用 Webpack 把所有后端 js 文件捆绑在一起,在我看来这真的没有必要。为什么要捆绑后端文件?我想我只是想运行后端,观察我的后端文件的变化,并使用 Webpack 的其余权力,只是为了前端。

如何在捆绑前端的同时运行后端 nodejs 部分?或者有什么好的理由将后端文件与 Webpack 捆绑在一起吗?

56590 次浏览

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 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.