Andrew Branch

You can’t generally assume that an import in an ESM file will resolve the same when you convert that file to a CJS context. This is by design, of course;...

`--module esnext` combined with `--moduleResolution nodenext` is not _super_ supported... at the very least, it’s playing the game on hard mode. I’m not quite sure why it “worked” in 4.7...

Agreed. Also related to https://github.com/microsoft/TypeScript/issues/48854. @weswigham thoughts?

> In https://github.com/microsoft/TypeScript/issues/51099 the goal is to actually make the import `any` If that’s the goal, I don’t think it’s a goal we should support. Whatever is the target of...

Aside from the crash, our checking for this appears to be super wrong right now.

I mean, sure, you can’t prove that `any` for the whole module type is wrong, but that value still conforms to `{ default: any }`. It represents the most specific...

I guess you’d have to assign or cast to `any` or a record of `any`. Or, of course, access them off `.default`

@typescript-bot perf test this

@cawoodm do you have the Deno extension for VS Code enabled? https://deno.land/[email protected]/vscode_deno My understanding is that the IDE experience with Deno is pretty well solved, so I’d like to understand...

I think you’re right that this would be fairly easy from an implementation standpoint, but there are two main reasons why we don’t want to move forward without careful consideration...