Double default wrapping @emotion/cache

[deviprsd]

Any reason why browser version for @emotion/cache is doubled wrapped in default

https://jspm.org/sandbox#H4sIAAAAAAAAA51V32/aMBB+719xy15AIg5p121lAdGurCpqqq0BaXs0iQGDf0SxUwbT/vc5dkCA2nXdQ+LEZ9/3fee7c/Qmk6le5wTmmrPeSbQdCM56JwARJxpDOseFIrrrlXrqf/SsQVPNSG8s7JhFgfvfbRGYk673SMkql4X2IJVCE2FcrGim592MPNKU+PanBVRQTTHzVYoZ6YYGIAocg2gis7X1+sb3zQAwTL7GcEMEKbCWBdzyyj/EOLfWQUY1jB/uOkaPzlUnCGbbpWihco6oDN7Gp/ezHzdXy+u4XayTzTAZh/N0sLjfJMFwEwejUfs83iznYXw9GscX6ebq8vPPb+KCDy8vDYjvWz4qLWiuoYpd11NrpQlfKJ9aOhznNki/LCfPTSqvU0+YqT7hUlMpghSnc2Is3o4vRs7bjq/IeedwfT8M0QcUBhlVOqgtvrWgSSFXihQoXSjjwLN4v1uOh0plTg5oPA+6t2qfLjcfdPMawvWOftswPj9kXJuOObeewFVzQvQrUO36fohC1D7EtIZ/QVwRvPRfL3d/m9F8utW8P/8XeKXXjKqX8dy6/jvURuGZQyh5Frjp3cGboz/ZvqsnClzWVrlZ1xQk1vkw6UBS5jZPgUmcUTEDLrOSEQU5Kaay4Fhotja1CpgxqCUomOB0CVrC7SAMoZGRnAi7WQpgdFLgYg3KOW4elY4q0u5LMuu66r9HYRvVQhXiVFQae0/pGYtUcm5azU4ZXOEJMYwJkyswQgALo8KvFcAggdgKhQBGppoTxy4wneY7mD4FK1ksp2Yv2vKvYP5DhD+peJikONuW7qHlUFINtsX7YnhrorQJbecwjj17xE4scq2mcdxfmkjPiWhw6PaqTqwkI4jJWYO3gKOMTHHJdLP56ZkUuTP5UAUN57nhCFNqYrUqqDYNvUoH4xrqDujVOQM2XzTIUuelhsYjxfAgGStzcxxBfSD74W4+Fduj3upcey7kjstxvKLA3Rfm+rD32B8b5dzH3wYAAA==

{ default: [Object], __esModule: true } { default: [Function: createCache] }

[guybedford]

This is because CommonJS conversion follows the Node.js semantics so that module.exports = { __esModule, default } is turned into a double default wrapper.

You can work around the issue by adding the module condition in the generator - then the "module" entry will be used from emotion, which you can see here - https://generator.jspm.io/#M2NhYGBkDM0rySzJSU1hcEjNzS/JzM/TT05Mzkh1MDTUM9czBAATEeXuJAA.

[deviprsd]

@guybedford I have figured this out like you said sometime today, but my biggest issue with "module" was process.env which isn't awfully hard to work around and I'm currently achieving it as such

(window as any).process = {
  env: {
    NODE_ENV: "production",
  },
};

I was hoping if there are any better ways to handle the process.env?

[guybedford]

@deviprsd yes it's a common issue - JSPM could easily handle process.env but follows the browser semantics so doesn't add magic like this by default. I usually post PRs like reactjs/react-transition-group#777 to libraries for this.

[deviprsd]

Being an early adopter of import-maps has been a journey, SystemJS here comes to your rescue but so far jspm is the only one to provide proper support for a SystemJS CDN.

I'm big supporter of it but there is a long way to go to a bundler free web world.

[jaydenseric]

@deviprsd

there is a long way to go to a bundler free web world.

I've been working full time for much of the last year on a zero build, Deno based SSR web framework utilising import maps and I'm getting closer to have solved the remaining problems (not relating to import maps). Along the way I've discovered some really cool techniques that are only possible with ESM and import maps, so I can't wait to share it all once it's ready!

Interestingly, I thought JSPM would be essential but it turns out after doing pure ESM right in almost all the dependencies they can be specified in the import map as being served raw from https://unpkg.com without any processing at all. JSPM is still the best thing when dependencies are not published correctly as pure ESM, but moving forwards I hope to avoid such situations.

[deviprsd]

@jaydenseric

I can't wait to share it all once it's ready!

I'll be looking out for it; I have very much made up my mind to go zero build, Deno and ESM. I have Learned a great deal from my company's mistakes and have been pushing them towards a transition state for the last year with Single-Spa (micro-frontend) which is also uses import-maps in its core through SystemJS.

Going full ESM is just a matter of the dependencies being used and if they support it, but I would be fine with tsc being my 1 step build. I have spend days researching and through trial & error ... trying to just get certain things to work just because how they are exported and which CDN provides the best conversion to work correctly.