Evan Wallace

> @evanw Do you plan on supporting code splitting with other formats apart from esm? Yes, that's why this issue is still open. However I want to fix issues with...

> does that imply that circular references cannot be built (since each file contains a reference to another)? Yes, code splitting currently generates an acyclic module graph. The current automatic...

> More confusing yet - if you have loaded chunk `A`, then navigate to an area that needs `B`, you could reasonably want `B - A` in order to avoid...

You have to explicitly enable code splitting with `--splitting`. It's not enabled by default. When enabled, every target of an `import()` expression is considered to be an entry point. So...

> This is why I think it's valuable to be able to (manually or otherwise) assign code to multiple chunks. If a library appears in multiple chunks, I'm not quite...

No, supporting these expressions by default is out of scope: https://esbuild.github.io/api/#non-analyzable-imports. You can either support them by switching on `language` and returning a statically-determined `import()` expression based on the value...

> Code splitting with dynamic `import()` of a JSON file that has key names at the root that would not be valid JavaScript identifiers yields incorrect named exports: > >...

This is by design. When plugins take control of module resolution, they are in control. If they are doing the wrong thing then that's a problem with the plugin, not...

> Even without the ability to transpile down to ES5, having the ability to not _introduce_ ES6 code during minification would make esbuild suitable for usage as a replacement for...

There's a lot left to do. Going off of http://es6-features.org/, it's something like this (for the syntax-level things at least): * Block-scoped variables * Default parameters * Rest parameters *...