Naila / Discord-chat-replica

Open Software License 3.0
24 stars 15 forks source link

Bump esbuild from 0.8.57 to 0.14.8 #109

Closed dependabot[bot] closed 2 years ago

dependabot[bot] commented 2 years ago

Bumps esbuild from 0.8.57 to 0.14.8.

Release notes

Sourced from esbuild's releases.

v0.14.8

  • Add a resolve API for plugins (#641, #1652)

    Plugins now have access to a new API called resolve that runs esbuild's path resolution logic and returns the result to the caller. This lets you write plugins that can reuse esbuild's complex built-in path resolution logic to change the inputs and/or adjust the outputs. Here's an example:

    let examplePlugin = {
      name: 'example',
      setup(build) {
        build.onResolve({ filter: /^example$/ }, async () => {
          const result = await build.resolve('./foo', { resolveDir: '/bar' })
          if (result.errors.length > 0) return result
          return { ...result, external: true }
        })
      },
    }
    

    This plugin intercepts imports to the path example, tells esbuild to resolve the import ./foo in the directory /bar, and then forces whatever path esbuild returns to be considered external. Here are some additional details:

    • If you don't pass the optional resolveDir parameter, esbuild will still run onResolve plugin callbacks but will not attempt any path resolution itself. All of esbuild's path resolution logic depends on the resolveDir parameter including looking for packages in node_modules directories (since it needs to know where those node_modules directories might be).

    • If you want to resolve a file name in a specific directory, make sure the input path starts with ./. Otherwise the input path will be treated as a package path instead of a relative path. This behavior is identical to esbuild's normal path resolution logic.

    • If path resolution fails, the errors property on the returned object will be a non-empty array containing the error information. This function does not always throw an error when it fails. You need to check for errors after calling it.

    • The behavior of this function depends on the build configuration. That's why it's a property of the build object instead of being a top-level API call. This also means you can't call it until all plugin setup functions have finished since these give plugins the opportunity to adjust the build configuration before it's frozen at the start of the build. So the new resolve function is going to be most useful inside your onResolve and/or onLoad callbacks.

    • There is currently no attempt made to detect infinite path resolution loops. Calling resolve from within onResolve with the same parameters is almost certainly a bad idea.

  • Avoid the CJS-to-ESM wrapper in some cases (#1831)

    Import statements are converted into require() calls when the output format is set to CommonJS. To convert from CommonJS semantics to ES module semantics, esbuild wraps the return value in a call to esbuild's __toESM() helper function. However, the conversion is only needed if it's possible that the exports named default or __esModule could be accessed.

    This release avoids calling this helper function in cases where esbuild knows it's impossible for the default or __esModule exports to be accessed, which results in smaller and faster code. To get this behavior, you have to use the import {} from import syntax:

    // Original code
    import { readFile } from "fs";
    readFile();
    

    // Old output (with --format=cjs) var __toESM = (module, isNodeMode) => { ... }; var import_fs = __toESM(require("fs")); (0, import_fs.readFile)();

    // New output (with --format=cjs) var import_fs = require("fs");

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.8

  • Add a resolve API for plugins (#641, #1652)

    Plugins now have access to a new API called resolve that runs esbuild's path resolution logic and returns the result to the caller. This lets you write plugins that can reuse esbuild's complex built-in path resolution logic to change the inputs and/or adjust the outputs. Here's an example:

    let examplePlugin = {
      name: 'example',
      setup(build) {
        build.onResolve({ filter: /^example$/ }, async () => {
          const result = await build.resolve('./foo', { resolveDir: '/bar' })
          if (result.errors.length > 0) return result
          return { ...result, external: true }
        })
      },
    }
    

    This plugin intercepts imports to the path example, tells esbuild to resolve the import ./foo in the directory /bar, and then forces whatever path esbuild returns to be considered external. Here are some additional details:

    • If you don't pass the optional resolveDir parameter, esbuild will still run onResolve plugin callbacks but will not attempt any path resolution itself. All of esbuild's path resolution logic depends on the resolveDir parameter including looking for packages in node_modules directories (since it needs to know where those node_modules directories might be).

    • If you want to resolve a file name in a specific directory, make sure the input path starts with ./. Otherwise the input path will be treated as a package path instead of a relative path. This behavior is identical to esbuild's normal path resolution logic.

    • If path resolution fails, the errors property on the returned object will be a non-empty array containing the error information. This function does not always throw an error when it fails. You need to check for errors after calling it.

    • The behavior of this function depends on the build configuration. That's why it's a property of the build object instead of being a top-level API call. This also means you can't call it until all plugin setup functions have finished since these give plugins the opportunity to adjust the build configuration before it's frozen at the start of the build. So the new resolve function is going to be most useful inside your onResolve and/or onLoad callbacks.

    • There is currently no attempt made to detect infinite path resolution loops. Calling resolve from within onResolve with the same parameters is almost certainly a bad idea.

  • Avoid the CJS-to-ESM wrapper in some cases (#1831)

    Import statements are converted into require() calls when the output format is set to CommonJS. To convert from CommonJS semantics to ES module semantics, esbuild wraps the return value in a call to esbuild's __toESM() helper function. However, the conversion is only needed if it's possible that the exports named default or __esModule could be accessed.

    This release avoids calling this helper function in cases where esbuild knows it's impossible for the default or __esModule exports to be accessed, which results in smaller and faster code. To get this behavior, you have to use the import {} from import syntax:

    // Original code
    import { readFile } from "fs";
    readFile();
    

    // Old output (with --format=cjs) var __toESM = (module, isNodeMode) => { ... }; var import_fs = __toESM(require("fs")); (0, import_fs.readFile)();

    // New output (with --format=cjs)

... (truncated)

Commits
  • 42a0aae publish 0.14.8 to npm
  • 5fc7b91 add a resolve API for plugins (#1881)
  • 3640cc9 service: overhaul reference counting
  • d8bacb4 service: use build key everywhere
  • 8361c88 add "on-" to stdio protocol
  • f38dcd3 update internal typescript version
  • c370315 uglify tests: enable issue_4464_3, which now works
  • 228478c release notes for #1864
  • 4fa3d7a fix #610: minify now drops overwritten functions
  • 70d1943 switch boolean flags on symbol to bitfield instead
  • Additional commits viewable in compare view


Dependabot compatibility score

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)
dependabot[bot] commented 2 years ago

Superseded by #110.