Reuses the same esbuild subprocess, and triggers rebuilds on file
changes. Esbuild will reuse parsed sources that are unchanged, so
subsequent builds are faster than the initial one
We were effectively ignoring our diagnostics, and instead falling back
to esbuild (and then displaying the esbuild diagnostics). That was
mostly for simplicity and so we would fall back to esbuild handling
unsupported things (for instance css imports).
This does a small refactor on the module loader to give us an API that
doesn't have to adhere to the deno_core ModuleLoader API. That lets us
return and handle errors more concretely, instead of having indirection
and downcasting.
Now, we only ignore our errors about being unable to load unsupport file
types, and the rest we handle ourselves.
I've also aligned the formatting of esbuild errors with ours, so it
should be more uniform. A few examples (dbgdeno is just an alias for the
debug build of this PR):

This further improves `import.meta.resolve` to not error in many more
scenarios (better alignment with Node).
1. Non-existent files in npm packages
1. Non-existent built-in node modules (ex. `node:non-existent`)
1. Many things that were previously errors with byonm.
1. No longer surfaces some deno_graph resolution errors
Additionally, this defers resolving npm specifiers until loading for
dynamic imports in order to have `prepare_load` properly install them
loading. Before it could potentially error when loading the same npm
specifier on multiple workers (reason for flaky
`specs::npm::worker_shutdown_during_npm_import`).
Closes#29650.
Currently passing `--platform=browser` does two things:
- makes us prefer the `"browser"` key in package json over module and
main
- makes us prefer the `"browser"` export condition
but we may add more things in the future
This is to help make this feature less ambiguous with `npm patch`, which
it's not like.
Note: the "patch" property will continue to work for the time being, but
the lockfile will have a bit of churn for this unstable property. We're
going to merge this in a patch because this feature is unstable.
todo:
- [ ] cleanup cli, decide what flags we want to commit to
- [x] decide what to do about node addons - (you can mark them external
via `--external`)
- [x] move `esbuild_rs` to the `denoland` org
- [x] figure out the dynamic require issue
- [x] figure out how to test this
- [x] clean up / revert all the random changes