`sources` paths are incorrect in declarationMap files (*.d.ts.map) emitted by tsdx

Current Behavior

When using the declarationMap option in tsconfig.json, the sources array in declaration map files does not contain correct relative paths. Repro steps:

1. git clone https://github.com/justingrant/ts-declaration-map-repro.git
2. cd ts-declaration-map-repro
3. yarn
4. yarn run with-tsc - this will simply run tsc against this repo.
5. Open ./dist/index.d.ts.map. It will begin with: {"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.tsx"]. Note the correct relative path to index.tsx
6. yarn run with-tsdx which uses tdsx instead of tsc but uses the same TS config.
7. Open ./dist/index.d.ts.map again. Here’s what you’ll see: {"version":3,"file":"index.d.ts","sourceRoot":"","sources":["src/index.tsx"]. Note that the path to index.tsx is incorrectly relative to the project root, not relative to dist.

Expected behavior

Correct relative path to index.tsx (../src/index.tsx) in the map file’s sources array.

Suggested solution(s)

I’m assuming that there’s a way to configure rollup-plugin-typescript2 so that declaration maps are emitted with the correct paths.

Additional context

Note that only declaration map files are affected. Relative paths in regular sourcemap files works fine.

I’m not sure if this is a problem with tsdx or rollup-plugin-typescript2. But I didn’t see any mention of this problem in rollup-plugin-typescript2’s issue list, so I figured that tsdx may be the culprit because it’s the new kid on the block. I’m assuming (perhaps naively) that if the problem was in rollup-plugin-typescript2 that it would have been reported in its GitHub issues already.

At first I thought that this problem was related to #465, but I think that issue is solely about how to handle the declarationDir config setting which I’m not using at all. Instead, I’m relying on the same outDir folder for both transpiled output and for declaration output.

This issue may be a dupe of #135, but I’m not sure, because #135 has a much more complex config. But the problem does look similar: in both issues the relative path to the source files is missing in declaration maps emitted by tsdx.

BTW, great library! Glad you’re building this.

Your environment

Software	Version(s)
TSDX	tsdx@0.12.3
TypeScript	typescript@3.7.5
Browser	n/a (this is a build issue)
npm/Yarn	yarn@1.21.1
Node	v12.13.1
Operating System	MacOS Catalina 10.15.2

[paynecodes]

@agilgur5 Thank you for your insightful reponse! If only more people know about declarationMap, I don’t think think they would want to work without it. At least not in a monorepo context 😉

[agilgur5]

Agreed. My outDir is ./dist. If that’s tsdx’s default then that explains why I didn’t notice any problems with outDir. 😉

Or rather, not yet you didn’t 😅😅😅 See https://github.com/jaredpalmer/tsdx/pull/468#issuecomment-581436403 for some of the other problems around outDir.

• remove tsconfig syntax (a trailing comma) that triggered #483, because that would have prevented verifying #468 because tsconfig.json was not parsed successfully. I didn’t think that my repo needed a repro for #483 because that repro was so obvious: just add a trailing comma or a comment to tsconfig.

Yea that change is fine and I agree I don’t think it necessarily needs a repro either. Though repros are always helpful so a maintainer doesn’t need to, like, create the code themselves. This case is also a bit unique as it’s a silent error, so you’d only notice when things are different from expected.

• clarify the case which is not going to be fixed by #468, which is the case when declarationDir is not included in tsconfig. AFAIK, the other case (where declarationDir is present) is already covered by unit tests included with #468.

Ok, gotcha. I think the original case is easier to understand the root cause, but that makes sense. Well, the unit tests don’t check that index.d.ts.map is correct – just that it exists – which is the core issue here.

Given the explanation above, would a new branch still be helpful? I’m happy to add another branch but I’m not sure what should be in it. Could you clarify what other repro(s) you think would be useful in this repo?

I think this is fine as at least I’ve already grasped it and will probably be the one to PR a fix. Thanks for the clarification around the changes!