v0.11.11

• Initial support for Deno (#936)

  You can now use esbuild in the Deno JavaScript environment via esbuild's official Deno package. Using it looks something like this:

  import * as esbuild from 'https://deno.land/x/[email protected]/mod.js'
  const ts = 'let hasProcess: boolean = typeof process != "null"'
  const result = await esbuild.transform(ts, { loader: 'ts', logLevel: 'warning' })
  console.log('result:', result)
  esbuild.stop()

  It has basically the same API as esbuild's npm package with one addition: you need to call stop() when you're done because unlike node, Deno doesn't provide the necessary APIs to allow Deno to exit while esbuild's internal child process is still running.

• Remove warnings about non-bundled use of require and import (#1153, #1142, #1132, #1045, #812, #661, #574, #512, #495, #480, #453, #410, #80)

  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 release 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.