It ended up being some arcane combination of config for... webpack, I think? Which is really weird because it seems to me "bundle all this in one file for web" is one of the countable-on-one's-fingers most-common use cases for a JS bundler, so should probably be available with a command line switch and no config file at all.
If I've found the right file (I was just trying to slap something together to try out a couple node modules in the browser... so much for that being quick & easy) then I ended up on an es5 target for TS, with "amd" module output. I've also got about a 12 SLOC webpack config file that specifies a single output "bundle.js".
The worst thing about troubleshooting shit like this is it's rarely clear what's broken. Is some part of the build choking on a bad ES-version + module combo (but just producing a broken build rather than, you know, fucking telling me that)? Is it a bundler config problem? Is Node at the wrong version(!)? So the troubleshooting process rapidly becomes combinatoric, which is an awful experience. You google some of these problems and see that everyone else is clearly going through the exact same "try one combination, see what happens, try the next" brute-force approach as you are. Meanwhile, again, the common use cases for these tools seem easily enumerable and quite tractable, so why they're driven indirectly by smashing together a bunch of implementation details until they work, rather than by explicitly stating which of a small number of common desired outcomes one wants and letting the build tools figure out how to make that happen in all but the most unusual cases, is baffling to me.
yeah I think I'm in the same boat, just not nearly as far as you. Thanks for the tips, I will give webpack a try (I was trying to use Parcel, but havent looked into browser-side yet)
It ended up being some arcane combination of config for... webpack, I think? Which is really weird because it seems to me "bundle all this in one file for web" is one of the countable-on-one's-fingers most-common use cases for a JS bundler, so should probably be available with a command line switch and no config file at all.
If I've found the right file (I was just trying to slap something together to try out a couple node modules in the browser... so much for that being quick & easy) then I ended up on an es5 target for TS, with "amd" module output. I've also got about a 12 SLOC webpack config file that specifies a single output "bundle.js".
The worst thing about troubleshooting shit like this is it's rarely clear what's broken. Is some part of the build choking on a bad ES-version + module combo (but just producing a broken build rather than, you know, fucking telling me that)? Is it a bundler config problem? Is Node at the wrong version(!)? So the troubleshooting process rapidly becomes combinatoric, which is an awful experience. You google some of these problems and see that everyone else is clearly going through the exact same "try one combination, see what happens, try the next" brute-force approach as you are. Meanwhile, again, the common use cases for these tools seem easily enumerable and quite tractable, so why they're driven indirectly by smashing together a bunch of implementation details until they work, rather than by explicitly stating which of a small number of common desired outcomes one wants and letting the build tools figure out how to make that happen in all but the most unusual cases, is baffling to me.