Investigate removal of generated `.d.ts.map` files

[mhofman]

#1025 introduced generated .d.ts files to enable types without requiring to parse JSDoc, which is a problem when consumed through NPM. However to keep "Go To Implementation" somewhat working, we also had to introduce declarationMap, which is kinda broken.

Now that VS Code plans to introduce a new way to get to the implementation if a .d.ts file exists, we should consider removing the declaration map if the experience is satisfactory.

[kriskowal]

I think @turadg has picked up this challenge. Assigning so they know to close.

[turadg]

The exports work is still generating d.ts.map from jsdoc, so running into the TS bug mentioned in the issue description. (Confirmed just now.)

My investigation shows that the new way to get to the implementation is not solving the problem.

When I clear out the maps (find node_modules/@endo -name '*.d.ts.map' |xargs rm) and try to navigate in VS Code (TS 4.7.4), it just takes me to the .d.ts. E.g.,

export function Far<T>(farName: string, remotable?: T | undefined): T & import("@endo/eventual-send").RemotableBrand<{}, T>;

So while the maps are buggy, they're better to keep. I'll close this work item to investigate as complete.

We still have the known issue of the maps going to the wrong place. That's a TS bug so I don't think we need to track that in Endo more than the history of this ticket.