SSR moduleIds not flushing

[chrisblossom]

I am sure I am missing something small here. I tried moving over from react-loadable, but am unable to get the server's moduleIds to flush correctly.

Any ideas?

react-universal-starter/tree/feature/extract-css-chunks-webpack-plugin

[faceyspacey]

ur doing externals correctly:

https://github.com/chrisblossom/react-universal-starter/blob/7b9e449f7dda8bce680fcac2930a1650ccf421cf/tools/webpack/server.js#L12

...um im not sure.

[faceyspacey]

are you sure it's not "blacklist". i dont use that package. ...but the goal is to make sure the given 3 packages are not assumed to exist externally. i.e. webpack has to handle them.

[faceyspacey]

to test whether the externals stuff has to do with the problem, remove it and dont use externals. if it works, then something is wrong there. if not, move to next possible problem area.

[faceyspacey]

...
according to the docs, there is no need to instantiate it with new, as u do here:
https://github.com/chrisblossom/react-universal-starter/blob/7b9e449f7dda8bce680fcac2930a1650ccf421cf/tools/webpack/server.js#L12

https://www.npmjs.com/package/webpack-node-externals

[chrisblossom]

Yeah, they are included. Was working with react-loadable. Wonder what is different. Going to try and investigate.

https://github.com/liady/webpack-node-externals#optionswhitelist:

An array for the externals to whitelist, so they will be included in the bundle.

Also, tried without new, same issue.

[faceyspacey]

• well make sure first u try without doing anything with externals
• try exactly as u have it now again with react loadable to see if something else changed
• ...u know u can open u node_modules folder, and go to the dist folder or whatever folder contains a package's entry script (as indicated in its package.json), and then add logging within the package itself
• also, u have the namedModulesPlugins twice:

https://github.com/chrisblossom/react-universal-starter/blob/7b9e449f7dda8bce680fcac2930a1650ccf421cf/tools/webpack/client.js#L166

https://github.com/chrisblossom/react-universal-starter/blob/7b9e449f7dda8bce680fcac2930a1650ccf421cf/tools/webpack/client.js#L208

[faceyspacey]

my guess it has to do with how you're making the moduleIds deterministic.

[faceyspacey]

but if ur not getting moduleIds from flushModuleIds(), then perhaps it has nothing to do with webpack-flush-chunks and deterministic module IDs. ..i saw u were logging this. if ur not getting anything, that means it's an issue react-universal-component, or probably require-universal-module.

Log the transpiled code within node_modules corresponding to this line in require-universal-modules:

export const flushModuleIds = (): Ids => {
  const ids = Array.from(MODULE_IDS)
  MODULE_IDS.clear()
  return ids
}

as well as this function:

  const addModule = (): void => {
    if (isServer) {
      if (chunkName) {
        CHUNK_NAMES.add(chunkName)
      }

      // just fill both sets so `flushModuleIds` continues to work,
      // even if you decided to start providing chunk names. It's
      // a small array of 3-20 chunk names on average anyway. Users
      // can flush/clear both sets if they feel they need to.
      if (isWebpack() && weakId) {
        MODULE_IDS.add(weakId)
      }
      else if (!isWebpack() && path) {
        MODULE_IDS.add(path)
      }
    }
  }

...if ur doing all this correctly, something is wrong with webpack stats and how ur getting it.

[chrisblossom]

What do you mean by "my guess it has to do with how you're making the moduleIds deterministic"?

Using a regex name match for webpack-node-externals fixed the issue. Although I am not exactly sure why. I am going to revert and try and see if the issue is with that library.

const nodeModules = nodeExternals({
    whitelist: [
        /^react-universal-component/,
        /^require-universal-module/,
        /^webpack-flush-chunks/,
    ],
});

[chrisblossom]

Also, thanks for catching the double NamedModulesPlugin. I am actually unsure why I switch to HashedModuleIdsPlugin in production. I'm pretty sure I was following your old boilerplate. Why did you change those plugins for production?

[faceyspacey]

so that module names aren't full file paths, exposing ur file system. instead it's a has hashes which obscures ur filesystem.

[faceyspacey]

deterministic means the same on both the client. usually module IDs are incrementing numbers, and the numbers end up different in the client vs. server bundle. thats why u gotta make them deterministic with one of those 2 plugins.

[faceyspacey]

for webpack flush chunks to work, what is initially flushed is the server side module IDs. then it searches through your client webpack stats using those module IDs to find the corresponding chunks. However if your client bundle had different module IDs, it would not work.

[chrisblossom]

Thanks for all of your help! I was wondering why'd you'd use NamedModulesPlugin in development and HashedModuleIdsPlugin in production, but webpack/webpack.js.org#652 seems to explain why.