Define browser main for esbuild-wasm

[guybedford]

This ensures bundlers and tools will properly support a browser build.

This can be done with "exports" too, but probably makes sense to use main / browser for a few months yet at least until Node.js 12 support can be assumed.

[evanw]

Thanks for taking the time to send a PR for this. However, I deliberately removed this recently. The esbuild APIs for node and the browser are different, and overlaying them like this is confusing in my opinion. It also prevents type checking from working properly because TypeScript currently doesn't have a way of selecting another main field (see microsoft/TypeScript#21423). I value having type checking for the API because I believe that IDE autocomplete is a good form of documentation. I really wish there was another way to make this work because I agree that having to import esbuild-wasm/lib/browser is aesthetically less than ideal, but type checking and API consistency seemed more important. What do you think?

[guybedford]

Typescript should ideally support this kind of branching - but that it doesn’t should not change implementation workflows. Users can depend on the wasm library and publish code to npm that works in Nodejs and browsers, but it only will work that way if the browser field is supported here. I specifically posted this PR myself to be able to use the project with jspm which currently will give a ‘child_process is not defined in the browser‘ error otherwise. There may be better ways to deal with the typing split though. Are the APIs not similar? Could the types ensure they provide a universal subset that works for both?

…

On Sat, Jul 11, 2020 at 12:09 Evan Wallace ***@***.***> wrote: Thanks for taking the time to send a PR for this. However, I deliberately removed this <bcc34c1#diff-b5d185f0de84464ad2f203174ceca1d1L11> recently. The esbuild APIs for node and the browser are different, and overlaying them like this is confusing in my opinion. It also prevents type checking from working properly because TypeScript currently doesn't have a way of selecting another main field (see microsoft/TypeScript#21423 <microsoft/TypeScript#21423>). I value having type checking for the API because I believe that IDE autocomplete is a good form of documentation. I really wish there was another way to make this work because I agree that having to import esbuild-wasm/lib/browser is aesthetically less than ideal, but type checking and API consistency seemed more important. What do you think? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#250 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAESFSQAIOOG2E4KKXWT6SDR3C2GXANCNFSM4OXJ6VTQ> .

[evanw]

There may be better ways to deal with the typing split though. Are the APIs not similar? Could the types ensure they provide a universal subset that works for both?

The APIs are similar but different. A common subset would eliminate all of the function declarations, making the type definitions useless (there's no API call that's the same in both APIs).

I suppose I could give up on accurate type information. I could turn both the node and browser APIs into a single API that is the union of both, and then "disable" certain API calls at run time by throwing exceptions when you make an API call from the other platform.