require function is used in a way in which dependencies cannot be statically extracted

I added console.log(require.ensure) to my code and it resulted in thousands of error lines from webpack. Had to increase my tmux scrollback to 40K lines to see what happened.

[...]
WARNING in ./src/routes.js
Critical dependencies:
158:18-25 require function is used in a way in which dependencies cannot be statically extracted
 @ ./src/routes.js 158:18-25

WARNING in ./src/containers/Admin/TODO.md
Module parse failed: /Users/olalonde/code/project/src/containers/Admin/TODO.md Unexpected token (1:13)
You may need an appropriate loader to handle this file type.

[...]

Not sure if it’s really a bug but would have been nice if that message had been isolated from all the subsequent thousands of error lines that are really irrelevant.

Author: Fantashit

13 thoughts on “require function is used in a way in which dependencies cannot be statically extracted

  1. with webpack@2, it’s reproduced again.

    function getAsyncComponent(path, chunkname) {
      return function(nextState, cb) {
        require.ensure([], function(require) {
          cb(null, require(path).default)
        }, chunkname)
      }
    }
    
    const Routes = (
      <Router history={browserHistory}>
        <Route path='/' getComponent ={ getAsyncComponent('./App.jsx','asyncApp') }>
          <IndexRoute component ={ Home} />
          <Route path='/hello' component = {Hello} />
          <Route path='author' component = {AuthorList}>
            <Route path= ':id' component = {Author} />
          </Route>
        </Route>
      </Router>
    
    )
    
    export default Routes;
  2. I understand there was a specific start to this thread, but the title indicates a more general issue that people find via Google searches. This being the use of variables in require() calls. It may help to change the title or open a new issue about console.log() if its desired to fix that. I don’t think that particular bug will be addressed, since require.ensure is documented already: https://webpack.github.io/docs/code-splitting.html#commonjs-require-ensure

  3. My problem was solved by making following change –

    FROM

    const moduleName = 'moduleName';
    
    function getComponent(location, cb) {
      require.ensure([], require => {
        cb(null, require('./components'));
      }, moduleName);
    }
    

    TO

    function getComponent(location, cb) {
      require.ensure([], require => {
        cb(null, require('./components'));
      }, 'moduleName');
    }
    

    i.e, avoiding the use of a const variable for the string ‘moduleName’.

    Don’t know the reason though. 😐

  4. My problem was a line in a library similar to

    var library = {};
    library.require = require;  // whyyyyy ಠ_ಠ
  5. The bigger problem here is that webpack doesn’t know what the result of resolve is. It’s just a random user function that can do anything at runtime.

    This is also not about tree-shaking, this is about knowing what to bundle in the first place. If webpack can’t see that you’re trying to look into the ../stories directory via simple string parsing, it doesn’t know that it needs to put the files inside ../stories in a context module.

  6. In case anyone else comes across this – I got this error because I was using "module": "umd" in my tsconfig.json. The solution was to use "module": "commonjs" instead – you can still get umd output by using libraryTarget: "umd" in webpack.config.js.

  7. You can get this error if you accidentally import something from /@angular/compiler instead of /@angular/core. With auto-import this can happen easily.

    For example this just happened to me when I used ChangeDetectionStrategy and VSCode suggested the compiler package – and I accepted it without realizing.

Comments are closed.