Async/Await in Build Output?

Hello again, @surma 😂

So I was having some funny build errors (Not working with closure compiler, and Webpack was sad). Then, I looked through the unpkg and found a bunch of non-ES5 friendly code 🤔

Is this by design? Usually bundlers will ignore anything in the node_modules, and I noticed in later versions things were transpiled down?

P.S it’s the end of the day for me, so I may just be done for the day 😂

[surma]

(TIL unpkg.com/browse, thanks for that!)

Yeah, I am following @justinfagnani’s guidance here. I publish untranspiled modules to npm. The reason for this is that publishing ES5 to npm has stifled our ecosystem’s ability to move forward. The fact that some bundlers will not transpile node_modules is actually the problem here. I am not sure if Webpack can be configured to behave otherwise.

FWIW, in my own projects I use TypeScript for transpilation and at that point you can just import the original TypeScript source file with an import:

import {expose} from "comlink/src/comlink.js";

That all being said: Is this just about async/await? If so, I only use it in one place and it’s probably fairly easy to rewrite that into a Promise chain.

[surma]

I will look into removing async/await from the code as it is only used in one function and probably easily avoided. But I won’t guarantee it. That being said:

You can specify to use “comlink/src/comlink.js” but the actual filesystem is named “comlink/src/comlink.ts” which causes errors to bubble up during webpack compilation when requesting the TS files directly or without extension because “protocols.js” is actually “protocols.ts” and the default settings won’t find it in most build tools.

This is a bug in Webpack. TypeScript has always worked this way in that it will automatically prefer a .ts file for a .js import. If Webpack does not behave this way, Webpack is breaking compatibility and convention here.

You have a variety of ways using package.json or yarn workspaces which could help you distribute this package for node/umd/clientside.

I am already making use of these fields. Neither main nor module imply transpilation to ES5, tho. Both CommonJS as well as ESM can contain async/await. As I stated above, the fact that some people expect ES5 to get published to npm has stifled our ecosystem’s ability to adopt modern JavaScript. Build tools like Webpack and Babel need to provide options to transpile dependencies. For Babel, for example, it’s just a matter of adjusting the exclude config option, I think.

What you have currently does not work unfortunately! I’m replacing with an alternative package because there is no minimal solution for fixing these problems.

Please do.