Next.js: Consider exposing resolved `webpack` configuration.

[wtgtybhertgeghgtwtg]

Feature request

next creates a webpack config and it'd be nice to have access to that.

Is your feature request related to a problem? Please describe.

Certain other tools, such as react-styleguidist, need to know how webpack is configured to work. But next abstracts this away and doesn't put it together until it spins up, so just require'ing a static file won't work. So, styleguidist can't share the webpack config that next uses.

Describe the solution you'd like

Ideally, it'd be something like the existing next/whatever imports.

const getWebpackConfig = require('next/webpack');
const webpackConfig = getWebpackConfig({ /* Some information on which one to get (client, server, build, dev) */ });

Describe alternatives you've considered

It's entirely possible to make an alternative webpack.config.js, but there's no guarantee that it'll stay in sync between versions or with add-on's, and it requires knowledge of what next is doing behind the scenes.

Another idea was to have next.config.js write the config to a file on require, but that can't copy over the functions and class instances in the config, since they are not serializable.

Since it's not bundled, stuff from next can be selectively required to kinda get the config

const loadConfig = require('next-server/next-config');
const getBaseWebpackConfig = require('next/dist/build/webpack-config').default;

const config = loadConfig(__dirname);
getBaseWebpackConfig(__dirname, {config, entrypoints: {}}).then(webpackConfig =>
  console.log('Config GET!', webpackConfig),
);

but that's messy, incomplete, depends on internals, asynchronous, and can entirely break for any number of reasons.

Additional context

[kyle-mccarthy]

Let me know if I am not understanding you correctly, but you can get access to the webpack config in the next.config.js file like so:

module.exports = (nextConfig = {}) => {
  return Object.assign({}, nextConfig, {
    webpack: (config, options) => {

      // access to webpack config here

      return config;
    },
  });
};

[wtgtybhertgeghgtwtg]

That's a function that composes part of the config, not the actual webpack config. It doesn't do any good unless next reads it and feeds it the right values, as it does in its build process.

[revskill10]

The simplest solution is ... duplicate the config to be used by reacft-styleguidist.
One babel.config.js with next/babel preset, then require .babelrc.js into your own babel.config.js will work out of the box.
The problem is, you can only know correct webpack config only after transpiling your NextJS project.

[wtgtybhertgeghgtwtg]

It can't be cleanly duplicated without relying on next internals, since next uses some customs loaders.

[revskill10]

@wtgtybhertgeghgtwtg Just use a console.log(nextWebpackConfig to a json file, and you'll know what's internal there. Then use it in an isolated webpack config.
The easy part is, with react-styleguidist, we only need webpack for client side.

[wtgtybhertgeghgtwtg]

console.log can't describe functions or classes, so, while it'd get some of the loaders, it wouldn't get the plugins.

[timneutkens]

At this point in time we're not planning to expose compilation internals. It's very likely to break between upgrades when the webpack config itself is being passed into another tool as Next.js adds in a bunch of very specific webpack plugins.

[stefvhuynh]

For those still looking for a way to view the final webpack config (and if there isn't a better way yet), go into /node_modules/next/dist/build/webpack-config.js and console.log the final config at the very end of the file.

Before doing this, I was just logging from next.config.js as someone suggested above. However, this does not give you the _final_ config, as execution of your custom webpack config doesn't happen at the end of the build. The build process goes through several more steps before it's all said and done.

[LukasBombach]

const getBaseWebpackConfig = require("next/dist/build/webpack-config").default;

const dir = "";
const buildId = "fakebuildid";
const distDir = "";
const pagesDir = "";
const entrypoints = { index: "" };

getBaseWebpackConfig(dir, {
  buildId: buildId,
  config: {
    experimental: {},
    distDir: distDir,
    pageExtensions: [],
    env: {},
    devIndicators: {},
    images: {},
    i18n: {},
    future: {},
    sassOptions: {},
  },
  pagesDir: pagesDir,
  entrypoints: entrypoints,
  rewrites: [],
})
  .then(config => console.log(config))
  .catch(error => console.error(error));

so.... this gets you _a next webpack config_ but I am pretty sure you should not do that, as @timneutkens pointed out, this is probably crazy-unstable and cannot be relied on