chore(deps-dev): bump esbuild from 0.8.57 to 0.11.11

Bumps esbuild from 0.8.57 to 0.11.11.

Release notes

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/esbuild@v0.11.11/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.

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.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/esbuild@v0.11.11/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.

... (truncated)

Commits

e2af734 publish 0.11.11 to npm
afd84e4 attempt to bypass weird ci heisenbug
0b9456d fix #936: announce deno support
32de4a0 remove "require" and "import" warnings (#1155)
e75f4ea add tests for deno (#1150)
deb4e17 don't duplicate warn about import namespace calls
62c8241 remove the now-unnecessary "rimraf" package
37c131e delete the fuzzer that doesn't work anymore
a2d1b2a publish 0.11.10 to npm
a14db0d fix typescript type checking tests
Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

windicss / windicss-webpack-plugin

chore(deps-dev): bump esbuild from 0.8.57 to 0.11.11 #45

v0.11.11

0.11.11