That output format thing is just weird. It hand-waves rather than describing what it actually does (“adapts the code automatically through static analysis” is vapid), and a large part of what I can only presume it is describing is flatly impossible: you can’t output something compatible with both ECMAScript Modules and CommonJS, for example, because they’re syntactically incompatible.

I do know that I dislike things that try to support CommonJS or AMD or just dropping things into global variables, because I will only ever want it in one way, but it’s wasting a few hundred bytes of code supporting the others. But I am zealous for dead code removal to a degree that most aren’t.

What I mean with "adapts the code through static analysis" is:

1. Finds dead code and removes it 2. It converts nodejs code that isn't compatible with the browser into browser code 2. It converts JS code that isn't compatible with nodejs to nodejs code

It tries to always make things work both in nodejs and browser js.

One example is the optional chain syntax which doesn't work in nodejs but works in the browser. FJB converts it to something that works everywhere.

> 2. It converts nodejs code that isn't compatible with the browser into browser code 2. It converts JS code that isn't compatible with nodejs to nodejs code

I’m not sure what that lot means. Are you talking about converting CommonJS to… I dunno, ECMAScript Modules? and vice versa? And there’s plenty that’s available in the NodeJS or web environments that’s simply unavailable in the other, e.g. the "http" and "https" modules from NodeJS and the fetch() global in the web, and you often can’t translate between the two at all, and even if you can, it’d be decidedly messy.

Output format is almost orthogonal to what I understand you to be talking about. In the terms of other bundling stuff, you seem to be talking more about features of Babel rather than features of webpack/Rollup, and if so, then output format is completely orthogonal.

Optional chaining's in Node as of v14.5.

Sure, but it was just an example of what kind of things FJB is doing to the code

> I’ve had enough trouble with ESBuild and SWC which don’t even warn about incompatibilities that I’m wary.

We're just in process of integrating ESBuild for stripping TypeScript types at work. I'd be interested to hear more about these incompatibilities you've encountered.

In one case it complained about the opening brace of a props spread on a JSX expression. In another case it complained about an unexpected question token with no line number so I couldn’t find what the issue was. In both cases they were perfectly valid TypeScript according to tsc and VSCode. For that usage I just gave up. It’s working well for me in other projects/contexts though.

It would be great if you could file these as bugs against esbuild! Sounds like these should be easy to fix.

It would be great and in the one case I will when I have space to come back to it, since I could isolate it. In the other case idk what to file other than “open source project I contribute to has a file with a question mark that your compiler doesn’t like”.

Both would be good to file. I’m happy to investigate myself if you don’t have the time.

One thing to be aware of is that some other tools that integrate esbuild do so incorrectly. For example, the 3rd-party integration of esbuild into Webpack mis-configures esbuild in a way that causes issues with JSX: https://github.com/privatenumber/esbuild-loader/pull/107. This isn’t a problem with esbuild itself.

I'm planning to make the typescript support an optional feature, so that one could integrate something else.

We will see.

Anyhow, appreciate your feedback.