Deno.transpileOnly gets stuck during transpile

[lucacasonato]

This script reliably does not complete for me. It gets stuck in one of the Deno.transpileOnly calls. Decreasing the amount of remote files to 4 causes the script to complete sometimes.

async function transpileRemote(name: string) {
  console.log("fetching", name);
  const resp = await fetch(name, {
    headers: {
      "user-agent": "Deno/v1.3.3",
    },
  });
  console.log("transpiling", name);
  const res = await Deno.transpileOnly(
    { [name]: await resp.text() },
    { lib: ["esnext", "dom"], jsx: "react", jsxFactory: "h" },
  );
  console.log("done", name);
  return res;
}

await Promise.all([
  transpileRemote(
    "https://cdn.skypack.dev/-/[email protected]/dist=es2020/preact.js",
  ),
  transpileRemote(
    "https://cdn.skypack.dev/-/[email protected]/dist=es2020/preact/hooks.js",
  ),
  transpileRemote(
    "https://cdn.skypack.dev/-/[email protected]/dist=es2020/preact-router.js",
  ),
  transpileRemote(
    "https://cdn.skypack.dev/-/[email protected]/dist=es2020/idb-keyval.js",
  ),
  transpileRemote(
    "https://cdn.skypack.dev/-/[email protected]/dist=es2020/preact.js",
  ),
  transpileRemote(
    "https://cdn.skypack.dev/-/[email protected]/dist=es2020/preact/hooks.js",
  ),
  transpileRemote(
    "https://cdn.skypack.dev/-/[email protected]/dist=es2020/preact-router.js",
  ),
  transpileRemote(
    "https://cdn.skypack.dev/-/[email protected]/dist=es2020/idb-keyval.js",
  ),
]);

OS: Ubuntu 20.04
Deno: 1.3.3

[kitsonk]

Hmmm... iIRC this will spin up the compiler isolate n times and there is complex promise resolution going on here with awaits inside awaits.

Not that it is a good answer, but what if you created a pipeline as a workaround, where you fetched all the remote assets and then transpiled them all in one shot, therefore only spinning up the compiler once?

[lucacasonato]

Not that it is a good answer, but what if you created a pipeline as a workaround, where you fetched all the remote assets and then transpiled them all in one shot, therefore only spinning up the compiler once?

I can check if this fixes it for this reproduction, but in the in the wild project this is actually occuring, the coordination of fetching and transpilation is done in rollup, so I can't change it much. I might be able to workaround there by adding a mutex for transpilation though.

[kitsonk]

Well, we need to reactor it to use swc anyway and reactor the APIs as a whole. So it may not make sense to try to fix it ATM.

[bartlomieju]

Well, we need to reactor it to use swc anyway and reactor the APIs as a whole. So it may not make sense to try to fix it ATM.

I agree, we shouldn't be spinning up TSC for Deno.transpile() it should be done using SWC in the same way as using --no-check flag.

[lucacasonato]

I agree, we shouldn't be spinning up TSC for Deno.transpile() it should be done using SWC in the same way as using --no-check flag.

This has to wait until 1.5 though as it would mean isolatedModules by default.

[kitsonk]

This has to wait for #4752 to be honest.

[bartlomieju]

I think this problem might be related to GlobalState::compile_lock being stuck - we could probably remove it altogether now, as there's no need to limit ourselves to a single compiler running at the same time. That wasn't the case. This issue is still valid.

[lucacasonato]

It seems to not be fixed by compiler refactor - can still reproduce on 1.5.2.

[lucacasonato]

Can not reproduce with Deno.emit anymore (both with and without typechecking).