swc transpiler returns undefined after first value is echoed

[cranberyxl]

This test passes w/o the --transpiler argument. I',m not sure if it's an swc or ts-node bug. I'll dig around, but maybe someone can point me in the right direction?

EDIT: Merged as part of #1602

[cspotcode]

When I need to debug the compiler's output, I open up node_modules/ts-node/dist/index.js or node_modules/ts-node/dist/repl.js, find where it invokes the .compile() function, and add a console.log to inspect the output. It's not pretty, but it's quick and it works well enough for the time being.

[cspotcode]

The way our repl works is that we pretend that every line of input goes into one typescript file, as if you had been entering those lines one after the other in an editor. Then we compile it, and then we use a diff library to figure out which lines of the compiled output are new. We assume that the new ones need to be eval'ed and we do that. Maybe the diffing is going wrong? Just a guess

[cspotcode]

I think I figured it out.

Somehow, the output from swc includes a trailing newline.

The diffing algorithm reports this change with swc:

{ count: 1, added: true, removed: undefined, value: '401;\n' }
{ count: 1, value: '\n' }
{
  count: 1,
  added: undefined,
  removed: true,
  value: '//# sourceMappingURL=data:application/json;charset=utf-8;base64,<redacted>'
}
{
  count: 1,
  added: true,
  removed: undefined,
  value: '//# sourceMappingURL=data:application/json;charset=utf-8;base64,<redacted>'
}

This is a tiny bit different from the diff we get without swc:

{
  count: 1,
  added: undefined,
  removed: true,
  value: '//# sourceMappingURL=data:application/json;charset=utf-8;base64,<redacted>'
}
{
  count: 2,
  added: true,
  removed: undefined,
  value: '401;\n' +
    '//# sourceMappingURL=data:application/json;charset=utf-8;base64,<redacted>'
}

I'm guessing that, somehow, that tiny difference affects the REPL's behavior. And if you can figure that out, maybe we can reliably avoid this bug by trimming newlines or something.

[cspotcode]

We take every "added: true" item in the diff and eval each one after the other. I believe we only return the evaluation result of the last eval. In the swc case, the diff has 2 additions: one with 401; and the other with the sourcemap comment.

When the sourcemap comment is eval-ed alone it evals to undefined, meaning with swc, you get undefined in the REPL when you should be getting 401.

Perhaps the solution is to remove the sourcemap comment before diffing?

[codecov]

Codecov Report

Merging #1478 (2e39370) into main (6e6bf63) will not change coverage.
The diff coverage is n/a.

[cspotcode]

@cranberyxl think you'll have time for a pull request? This should be a straightforward change; just remove any trailing sourcemap comment before diffing in the REPL. Probably can be done with a regexp.

[cranberyxl]

I can't figure out how to run this stuff locally or where it's happening in the code. Is there some documentation on that? Is there a way to run a single test?

[cspotcode]

Yeah, I usually do this: ``` npm run test-local -- --match '*test name substring*' ``` We use ava, so I use Ava's --match flag to pick a test to run.

…

On Sun, Oct 10, 2021, 10:12 AM Andy Stanberry ***@***.***> wrote: I can't figure out how to run this stuff locally or where it's happening in the code. Is there some documentation on that? Is there a way to run a single test? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1478 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35OBDLRKDH3NEFIXHIF3UGGNMBANCNFSM5E6QUG7Q> .

[cspotcode]

I've merged VSCode debug configurations to the main branch. If you prefer to use a debugger, opening a .spec.ts file and pressing "F5" should "just work" and hit breakpoints that you've set in that file.

[cspotcode]

@cranberyxl any luck putting together a PR for this?