BUG: Unable to create dew wrapper for this file.

[AlexVasiluta]

Hello!

I was trying to use postcss in Deno with the autoprefixer plugin, but when Deno tried fetching it, this URL spews out Unable to create dew wrapper for this file. with a 500 status code. Is it possible to find a fix for it?

A minimal command to help reproduce this bug is deno run https://dev.jspm.io/autoprefixer and returns the following:

error: Import 'https://dev.jspm.io/npm:nanoid@3.1.20/non-secure/index.dew.js' failed: 500 Internal Server Error
    at https://dev.jspm.io/npm:nanoid@3/non-secure?dew:1:0

To prove this is not a deno-specific bug, an html file with just a <script type="module" src="https://dev.jspm.io/autoprefixer"></script> line will also break at that specific file when opened in the browser.

If you have any more specific questions in hope of finding a solution, feel free to ask.

[guybedford]

@AlexVasiluta the dev.jspm.io CDN is deprecated actually - have you tried using the replacement jspm.dev CDN?

[AlexVasiluta]

Hey! I have tried replacing dev.jspm.io with the jspm.dev CDN, and it now displays a few syntax errors for the following minimal example (this is now how I do it, but I want you to be 100% sure that this is not a deno-exclusive bug):

<script type="module" src="https://jspm.dev/cssnano"></script>
<script type="module" src="https://jspm.dev/tailwindcss"></script>

I do not know if syntax errors for the transpiling part are guaranteed to be fixed in this service, and I'm sorry if I'm wasting your time!

[guybedford]

There's likely a couple of issues here, happy to dig into them though.

For cssnano, the problem is with this dependency - import('/npm:dom-serializer!cjs') which returns an object like { default, __esModule } where it ends up needing to access .default.default is the problem. This is the classic interop problem where Node.js interprets CommonJS modules module.exports = ... as being a module like { default } while bundlers automatically collapse the __esModule flag to treat it like a fake ES module. See https://nodejs.org/dist/latest-v15.x/docs/api/esm.html#esm_commonjs_namespaces for more info here.

It's basically the painful edge case, and libraries are best to avoid this scenario entirely. Babel even has a PR to fix this problem.

Ideally, posting an issue to dom-serializer about the interop case and how to avoid it would be worthwhile. Since it's a situation where Node.js and jspm (which follows Node.js interop) and other tools differ it's usually best for tools to avoid emitting a module.exports = { __esModule, default } style module as CommonJS for their entry point entirely.

Would you be open to posting such an issue? Otherwise I'm happy to try bring it up too.

As far as I can tell import('tailwindcss') seems to be working.

Btw you'd usually want to write:

<script type="module">
import cssnano from 'https://jspm.dev/cssnano';
import tailwindcss from 'https://jspm.dev/tailwindcss';
</script>

[AlexVasiluta]

Thanks so much for the help! I didn't know about this edge case, and now I sure am not going to use this problem if I ever publish an npm package! :)

I think it would be most appropriate for you to open an issue on that project, since I do not have a good enough knowledge about the problem in order to properly report it and suggest fixes for it.

Again, thanks so much for your help!