Stack overflow when emitting ESM package

[NfNitLoop]

Steps to reproduce:

1. Check out this commit: https://github.com/NfNitLoop/feoblog-client/commit/ba0de8f73f47f726307edae5a90006e00d5e52d1
2. run deno task build-npm

Output:

PS C:\Users\Cody\code\feoblog-client> deno task build-npm
Warning deno task is unstable and may drastically change in the future
Task build-npm deno run -A ./build/npm.ts
[dnt] Transforming...
[dnt] Running npm install...

added 12 packages, and audited 13 packages in 3s

2 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
[dnt] Building project...
[dnt] Emitting declaration files...
[dnt] Emitting ESM package...
error: Uncaught (in promise) RangeError: Maximum call stack size exceeded
    function visitEachChild(node, visitor, context, nodesVisitor, tokenVisitor, nodeVisitor) {
                           ^
    at Object.visitEachChild (https://deno.land/x/ts_morph@15.1.0/common/typescript.js:89515:28)
    at visitorWorker (https://deno.land/x/ts_morph@15.1.0/common/typescript.js:94391:23)
    at visitor (https://deno.land/x/ts_morph@15.1.0/common/typescript.js:94397:20)
    at visitNode (https://deno.land/x/ts_morph@15.1.0/common/typescript.js:89313:23)
    at Object.visitEachChild (https://deno.land/x/ts_morph@15.1.0/common/typescript.js:89735:61)
    at visitorWorker (https://deno.land/x/ts_morph@15.1.0/common/typescript.js:94391:23)
    at visitor (https://deno.land/x/ts_morph@15.1.0/common/typescript.js:94397:20)
    at visitNode (https://deno.land/x/ts_morph@15.1.0/common/typescript.js:89313:23)
    at Object.visitEachChild (https://deno.land/x/ts_morph@15.1.0/common/typescript.js:89735:61)
    at visitorWorker (https://deno.land/x/ts_morph@15.1.0/common/typescript.js:94391:23)

[NfNitLoop]

FWIW, still seeing this error (w/ a slightly different codebase) in dnt v0.32.0, ts-morph v17.0.1.

I'm looking into it a bit more because I'd really like to make Deno the canonical source for this library. :)

It turns out that if I just give it some more stack to work with, it completes:

easy to reproduce with these deno tasks:

        "build-npm-debug": "deno run -A --v8-flags=--stack-trace-limit=999999 ./build/npm.ts",

        //works:
        "build-npm-bigstack": "deno run -A --v8-flags=--stack-size=2000 ./build/npm.ts",

        // doesn't:
        "build-npm": "deno run -A ./build/npm.ts",

---

Unfortunately, "completes" means it tells me that it can't find a type:

> deno task build-npm-bigstack
Task build-npm-bigstack deno run -A --v8-flags=--stack-size=2000 ./build/npm.ts
[dnt] Transforming...
[dnt] Running npm install...

added 26 packages, and audited 27 packages in 4s

3 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
[dnt] Building project...
[dnt] Type checking...
src/private/shim.ts:6:24 - error TS7016: Could not find a declaration file for module 'bs58check'. 'C:/Users/Cody/code/feoblog-client/npm/node_modules/bs58check/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/bs58check` if it exists or add a new declaration (.d.ts) file containing `declare module 'bs58check';`

6 import * as bs58c from "bs58check"
                         ~~~~~~~~~~~

error: Uncaught (in promise) Error: Had 1 diagnostics.
        throw new Error(`Had ${diagnostics.length} diagnostics.`);
              ^
    at build (https://deno.land/x/dnt@0.32.0/mod.ts:315:15)
    at async file:///C:/Users/Cody/code/feoblog-client/build/npm.ts:6:1

Now, when I import that from esm.sh like this:

import * as bs58c from "https://esm.sh/bs58check@2.1.2"

I get types. So esm is properly providing types to me. Shouldn't dnt just use those?

In the meantime I'm working around it by explicitly grabbing the type bindings by adding devDependencies to my build/npm.ts:

        devDependencies: {
            "@types/bs58check": "*",
        }

And now we're on to other shimming problems which I'll look into later. Sorry for the train-of-thought. Just trying to capture the use case of a new user. Several issues here that could probably be pulled out into their own tickets. Happy to do so if that helps:

• More stack space by default?
• Grab types from esm.sh?
• Whatever the next breaking thing is. :p

[NfNitLoop]

FWIW, the workaround for my case was to stop using the library that was causing the issue. Not sure what about that library was causing the issue, but it was an easy enough work around. Once I figured out which library was causing the issue, which required firing up a debugger, because the error condition didn't make that clear.

So maybe another potential feature/improvement request is: add information about the current library being transformed to the output so that users can figure out which part failed more easily. :)

Super happy to have this working now. Thanks for making DNT!