Batch of several breaking changes #2508
Conversation
evanw
force-pushed
the
breaking
branch
2 times, most recently
from
98ab5ea to
20d66fe
Compare
evanw
force-pushed
the
breaking
branch
2 times, most recently
from
be3af6e to
5523958
Compare
|
I'm really looking forward to this, thanks for the URL change in particular! I've tried testing this locally by doing /Users/lgarron/Code/git/github.com/cubing/cubing.js/node_modules/esbuild/lib/main.js:1624
let error = new Error(`${text}${summary}`);
^
This may be because I'm only using the latest package from Do you have a recommended way one could test out these changes? |
If you want to try out the command line you just need to type |
I see. Unfortunately, that doesn't quite work if |
|
The returned object has a |
evanw
force-pushed
the
breaking
branch
3 times, most recently
from
2ea2cba to
5ca835b
Compare
|
Will variadic imports be eager or lazy? It'd be quite nice if we could configure that on a case-by-case basis. Webpack does this via comment annotations: await import(/* webpackMode: eager */ `./icons/${name}.png`)
await import(/* webpackMode: lazy */ `./pages/${page}.tsx`)(Also very useful, but perhaps out of scope for this iteration, is |
That would be a separate feature, and isn't addressed here. What you are calling "variadic imports" are handled the same way normal dynamic imports are handled. Right now the equivalent behavior for esbuild (in the same chunk vs. a new chunk) is configured with the splitting parameter. In the future I hope to make it possible for plugins to reconfigure which chunk(s) a given module ends up in, but that will require rewriting how esbuild's linker works. I plan to do that in a separate release. |
Thanks!
Okay, I figured out what broke — it seems to be the use of a plugin: // build.js (run with: `node ./build.js`)
import { build } from "esbuild";
build({
format: "esm",
target: "es2020",
splitting: true,
bundle: true,
outdir: "/tmp/esbuild-test",
loader: { ".jpg": "copy" },
entryPoints: ["./entry.ts"],
plugins: [{
name: "notify-on-end",
setup(build) { build.onEnd(() => console.log("onEnd!")) }, // Do almost nothing
}],
});// entry.ts
const url = new URL("./cubing.js.jpg", import.meta.url).toString();
console.log(url);It seems that the issue still occurs when the I can also confirm that commenting out our plugin allows |
evanw
force-pushed
the
breaking
branch
7 times, most recently
from
4089cf8 to
7a44d63
Compare
This should be fixed now. Thanks for reporting it. |
|
Firefox Nightly is now able to instantiate module workers, which hopefully means that |
|
@evanw: If these breaking changes are too much to land in the short term, could I ask/suggest support for Since the time this PR was originally created, As long as the path argument is handled as part of the import graph, it can be:
I'd be happy to send an updated version of this PR if that would help. |
|
Chiming in that I'm currently falling over a legacy app using |
|
@evanw sorry to pester but would love to get the dynamic import feature in. Is there anything I can do to help? |
|
If I may, I'd like to just comment on the usage of We at PeacockTV and SkyShowtime need to support all kinds of TVs and set-top boxes, some of which were launched more than 10 years ago. Some of these are based on older versions of Chromium, and lack |
|
Hi! I deleted my previous comment because there were ... a lot of different things going on there. But, in any case, even after working around some problems in Emscripten, this change does not work for loading WebAssembly files that its ES6 module support outputs. You can see a minimal example here: https://github.com/dhdaines/webpack-wasm-test by running (assuming the If you look in where the input was: This is obviously wrong! It will result in the code trying to load the JavaScript wrapper file as WebAssembly. By contrast, webpack will output the There is also an issue with Emscripten's wrapper code doing |
|
Basically I think the only reasonable way for a bundler to support |
|
Should also note that in the case that the target of |
|
I love esbuild and I'm waiting for you to officially support ESM capability in worker. |
|
FYI: The glob pattern part of this PR has been released in version 0.19.0. The documentation for this feature is here: https://esbuild.github.io/api/#glob. |
|
@evanw do you think that the URL syntax for bundling is something that you'll continue exploring at this point or are we waiting for more clear signals from the ecosystem on how to tackle these sorts of non ESM import / export bundle boundaries? |
|
whats up? |
|
FWIW, I don't think the files referenced using If, as a user of esbuild, you need to reference another JS bundle from a This would make the use of |
|
If you do want to support adding referenced JS files to the bundle, then I would suggest to add an argument to the cli: In this scenario, only the |
This is what I found when looking how to do it: evanw/esbuild#2508 evanw/esbuild#312
|
@evanw having this being merge will fix multiple issues in Vite dependency optimizer. We plan to have this working by default on Rolldown, but this is still far from being usable in Vite. |
This is a batch of several breaking changes. I'm planning to release them together in an upcoming release. TL;DR:
new URL(...)and globimport(). In detail:Interpret and rewrite
new URL(..., import.meta.url)expressions when bundling (#312, #795, #2470)Some other bundlers have adopted a convention where the syntax
new URL('./file.js', import.meta.url)causesfile.jsto be included in the current bundling operation as an additional entry point. The'./file.js'string is rewritten in the bundler's output to point to the resulting generated file for that entry point in the output directory (relative to the generated file containing thenew URL(...)syntax). This is somewhat similar to howimport('./file.js')works except that this reference just returns aURLobject without importing the module. That lets you pass the URL of a module to other APIs such asnew Worker(...)that take a script URL as input.Previously this pattern didn't work at all with esbuild, but it will now work in esbuild starting with this release. To use it you must ensure that bundling is enabled, that the output format is set to
esm, and that code splitting is enabled (so you need to use--bundle --format=esm --splitting). In addition, the path must be a relative path (i.e. it must start with either./or../). Here's what using this feature looks like:Handle import paths containing wildcards (#56, #700, #875, #976, #2221, #2515)
This release introduces wildcards in import paths in two places:
Entry points
You can now pass a string containing glob-style wildcards such as
./src/*.tsas an entry point and esbuild will search the file system for files that match the pattern. This can be used to easily pass esbuild all files with a certain extension on the command line in a cross-platform way. Previously you had to rely on the shell to perform glob expansion, but that is obviously shell-dependent and didn't work at all on Windows. Note that to use this feature on the command line you will have to quote the pattern so it's passed verbatim to esbuild without any expansion by the shell. Here's an example:esbuild --minify "./src/*.ts" --outdir=outSpecifically the
*character will match any character except for the/character, and the/**/character sequence will match a path separator followed by zero or more path elements. Other wildcard operators found in glob patterns such as?and[...]are not supported.Run-time import paths
Import paths that are evaluated at run-time can now be bundled in certain limited situations. The import path expression must be a form of string concatenation and must start with either
./or../. Each non-string expression in the string concatenation chain becomes a wildcard. The*wildcard is chosen unless the previous character is a/, in which case the/**/*character sequence is used.This feature works with
require(...),import(...), andnew URL(..., import.meta.url)because these can all accept run-time expressions. It does not work withimportandexportstatements because these cannot accept run-time expressions.