Currently, esbuild does not support and may never natively support a umd target (See: https://github.com/evanw/esbuild/issues/507). However, many build tools or default configurations for web app framework scaffolding tools still unfortunately make a variety of assumptions that result in iife targets insufficient as a "fallback" case (our current strategy). Luckily, since the primary difference between esbuilds iife and a umd build is header/footer content in the resultant .js file (with some *'s around e.g. bundled vs. unbundled that are irrelevant to our usage), someone has built a plugin for this 🎉 (See: https://github.com/Inqnuam/esbuild-plugin-umd-wrapper).
This PR replaces our iife build (and its corresponding identifications in package.json) with a umd flavor instead. Furthermore, I've confirmed that this resolves the default parcel usage locally via a local link.
This will hopefully also resolve the various other build scenarios called out in #88
… this case.
Currently,
esbuilddoes not support and may never natively support aumdtarget (See: https://github.com/evanw/esbuild/issues/507). However, many build tools or default configurations for web app framework scaffolding tools still unfortunately make a variety of assumptions that result iniifetargets insufficient as a "fallback" case (our current strategy). Luckily, since the primary difference betweenesbuildsiifeand aumdbuild is header/footer content in the resultant .js file (with some *'s around e.g. bundled vs. unbundled that are irrelevant to our usage), someone has built a plugin for this 🎉 (See: https://github.com/Inqnuam/esbuild-plugin-umd-wrapper).This PR replaces our
iifebuild (and its corresponding identifications in package.json) with aumdflavor instead. Furthermore, I've confirmed that this resolves the defaultparcelusage locally via a local link.This will hopefully also resolve the various other build scenarios called out in #88