remove "require" and "import" warnings

[evanw]

Previously esbuild had warnings when bundling about uses of require and import that are not of the form require(<string literal>) or import(<string literal>). These warnings existed because the bundling process must be able to statically-analyze all dynamic imports to determine which files must be included. Here are some real-world examples of cases that esbuild doesn't statically analyze:

• From mongoose:

  require('./driver').set(require(global.MONGOOSE_DRIVER_PATH));

• From moment:

  aliasedRequire = require;
  aliasedRequire('./locale/' + name);

• From logform:

  function exposeFormat(name) {
    Object.defineProperty(format, name, {
      get() { return require(`./${name}.js`); }
    });
  }
  exposeFormat('align');

All of these dynamic imports will not be bundled (i.e. they will be left as-is) and will crash at run-time if they are evaluated. Some of these crashes are ok since the code paths may have error handling or the code paths may never be used. Other crashes are not ok because the crash will actually be hit.

The warning from esbuild existed to let you know that esbuild is aware that it's generating a potentially broken bundle. If you discover that your bundle is broken, it's nice to have a warning from esbuild to point out where the problem is. And it was just a warning so the build process still finishes and successfully generates output files. If you didn't want to see the warning, it was easy to turn it off via --log-level=error.

However, there have been quite a few complaints about this warning. Some people seem to not understand the difference between a warning and an error, and think the build has failed even though output files were generated. Other people do not want to see the warning but also do not want to enable --log-level=error.

This PR removes this warning for both require and import. Now when you try to bundle code with esbuild that contains dynamic imports not of the form require(<string literal>) or import(<string literal>), esbuild will just silently generate a potentially broken bundle. This may affect people coming from other bundlers that support certain forms of dynamic imports that are not compatible with esbuild such as the Webpack-specific dynamic import() with pattern matching.

Related past issues:

• Fixes Checking for existence of require in if throws warning #1153
• Would love a way to silence the "indirect calls to require" warnings for 3rd party dependencies #1142
• This call to "require" will not be bundled because the argument is not a string literal (surround with a try/catch to silence this warning) #1132
• require.main not working #1045
• Warnings for use of require.cache #812
• [Question] Dynamic imports #661
• Dynamic import(): how to ignore an import that’s passed a variable? #574
• Is it possible to suppress a warning via a comment? #512
• Doesn't seem to like vm2 b/c of a library 'contextify' #495
• logform library uses non-string literals in require and fails at runtime, but works with webpack #480
• Remove warning about using dynamic imports #453
• false positive: use of require.resolve causes unexpected warning (v0.7.4) #410
• indirect access of 'require' #80

[mattfysh]

Nice :) Wondering if instead of a build time warning, could the offending code be modified to log out a warning if the code path is entered at runtime?

[evanw]

A note for anyone who ends up here:

You may be able to get more information to debug a crash due to unbundled require or import by using --log-level=debug. Logging of debug information for some of these cases was added in a later release. The difference is that the log level defaults to info so debug information is not logged by default.

[evanw]

With the latest release, you can now use --log-override:unsupported-require-call=warning to make this a warning again (or --log-override:unsupported-require-call=error to make this an error).