Universal Webpack or universal Babel

[sedubois]

As mentioned in #867 (comment) and #627 (comment), it sounds possible to use Webpack universally. There's e.g the universal-webpack package which might help, and this article gives some tips and an example.

If it can be done efficiently, having a universal Webpack sounds like a great way to reduce the complexity of the Next.js codebase and would allow users to load any Webpack plugin they need?

What's Next.js' team's opinion on this, does it make sense and should it be investigated?

[arunoda]

Having a such a system is nice. That's what we wanted ultimately.
But that solution seems like a bit of an experiment.

What we have today is a subset of Webpack but it's production ready.
And we've total control of how things works.

So, in the short-term we won't be able to hook into such system.

[sedubois]

Why would universal Webpack be more of an experiment than the Webpack + Babel combo?

Why couldn't we have total control of how things work, with a universal Webpack setup?

[davidrossjones]

Completely agree with @sedubois and @ccorcos (via #867).

I previously alluded to this in #658 and your linked comment above that mentions universal-webpack.

I too would love to see Next.js work with a full Webpack setup using target: node and pre-compiling on the server side. Much like is achieved via nuxt.js (a project inspired by Next.js) here: https://github.com/nuxt/nuxt.js/blob/master/lib/webpack/server.config.js

Babel plugins don't offer the same functionality as Webpack and I ❤️ SSR with Next.js so for me (and much of the community) this is a must have feature!

[sakulstra]

👍 then we could finally use libraries like which require us to import the css/scss manually without a hassle (e.g. https://github.com/Hardtack/react-material-components-web)

[ericclemmons]

I've been doing universal webpack apps successfully for well over a year now (I have a terrible sense of time, but it's been in production for over that long!), and here's a quick way of doing it with next:

// package.json scripts
"dev": "./node_modules/next/node_modules/.bin/webpack --config webpack.config.server.js --hide-modules --watch",

// webpack.config.server.js
require("source-map-support/register");

const CaseSensitivePathPlugin = require("case-sensitive-paths-webpack-plugin");
const FriendlyErrorsWebpackPlugin = require("friendly-errors-webpack-plugin");
const StartServerPlugin = require("start-server-webpack-plugin");
const webpack = require("webpack");
const nodeExternals = require("webpack-node-externals");

process.env.NODE_ENV = process.env.NODE_ENV || 'development'

const dev = process.env.NODE_ENV === "development"
const createCompiler = require("next/dist/server/build/webpack").default;

module.exports = createCompiler(".", { dev }).then((compiler) => {
  const server = Object.assign({}, compiler.options, {
    devtool: "inline-source-map",
    entry: {
      "server.js": [
        "webpack/hot/poll?1000",
        "./server.js",
      ],
    },
    externals: [
      /^@?\w[\w\-0-9\./]+$/,
    ],
    module: {
      rules: [
        {
          exclude: /node_modules/,
          loader: "babel-loader",
          options: {
            cacheDirectory: true,
            sourceMaps: dev ? 'both' : false,
          },
          test: /\.js(\?[^?]*)?$/,
        },
      ],
    },
    node: { __dirname: true, __filename: true },
    plugins: [
      new CaseSensitivePathPlugin(),
      new FriendlyErrorsWebpackPlugin(),
      new StartServerPlugin(),
      new webpack.HotModuleReplacementPlugin(),
      new webpack.NamedModulesPlugin(),
    ],
    target: "node",
  });

  return server;
});

From there I borrowed server.js from https://github.com/ericclemmons/webpack-hot-server-example/blob/master/src/server.js and used the custom-server-express example (minus the .listen call) and was off to the races!

[migueloller]

Just wanted to chime in and mention that if universal Webpack gets supported, it will fix issues such as #364 as well as reducing a lot of confusion around different behavior between client and server.

[kjs3]

Using webpack server-side would be especially nice for asset fingerprinting. This BUILD_ID PR not only lets you cache-bust assets, it forces cache-busting which is pretty heavy-handed. Typically, none of my assets change between deploys and when they do it's usually just a few files. Hashing the file keeps the fingerprint the same until bits change.