Would I be correct in assuming this is added because the tsconfigs used for dtslint don't use a module resolution mode that supports the imports/exports fields so the build is necessary so preconstruct outputs stuff that for the default case doesn't require supporting the imports/exports fields?

seems like the answer is yes from reading the commits

it's not even that - although when you mention this, I think I could now remove resolved-condition.ts files and the associated configs

the core of the problem fixed by this is that older TS versions might trip on some new syntax. We are OK with using more modern TS in /src (like even satisfies) as long as the emitted declarations are free of the modern syntax. dtslint tests a range of TS versions so the older ones were tripping over new syntax when reading directly from /src. That said, we could just change the min required TS version (or rather, the min TS version that we test against) but it felt nicer not to do that just for this reason.

testing against compiled types is also safer for us, I've seen some declaration emit regressions in TS - especially recently when a lot of the internals were changed in isolatedDeclarations-related work

What's the new @ts-ignore for? Does the comment in the false case get moved around when generating the .d.ts file?

Seems like the answer is the comment gets removed but if that's true, shouldn't the comments be updated for the types above as well? Seems like you "fixed" it for the tests by bumping @types/react but that wouldn't fix it for consumers?

Maybe keeping this in a .d.ts file might make sense so we don't have to rely on comments being preserved in particular places? (don't have strong feelings about that though, just an idea)

the one we had was removed, a JSDoc-style comment - in general - should be preserved but perhaps they are only preserved on accessible symbols. In the emitted declaration this gets folded into a single line and the new comment stays in place.

Seems like you "fixed" it for the tests by bumping @types/react but that wouldn't fix it for consumers?

I was checking the emitted declaration files and this shouldn't affect consumers (for the reason outlined above). That said... now I'm surprised why this was erroring with the new @types/react in the first place. I updated the types before fighting this 🤔

Maybe keeping this in a .d.ts file might make sense so we don't have to rely on comments being preserved in particular places? (don't have strong feelings about that though, just an idea)

I agree it's not ideal but also not a big deal. The general mantra I've heard (from the TS team members too) is that .d.ts shouldn't quite be used when authoring libs in TS. I don't recall the exact reasons behind this though. Testing things out in TS workbench (see this)... it seems that TS might not even "copy over" dts files into the distDir. You can see the output in the Debug tab in the "Virtual File System" section

I mean, we could also just keep this .d.ts outside of src... but ugh, I don't feel overly confident that all of the relative paths would be rewritten correctly. Authoring everything in src feels safer/better

Continued in #3282

Am I correct in understanding that these two are equivalent? (since the former compiles into the latter)

export namespace Blah {
  export type Something = A
}

export declare namespace Blah {
  type Something = A
}

loling at

export namespace Blah {
  type A = {}
  export type Something = A
}

getting compiled into

export declare namespace Blah {
    type A = {};
    export type Something = A;
    export {};
}

(I know the context around export {};, just never thought about it for namespaces lol)

Ye, those rules are super trippy tbh. I just slapped export onto those because they suddenly became unavailable when I moved this from an ambient content to .ts 🤷‍♂️

Seems like the answer is the comment gets removed but if that's true, shouldn't the comments be updated for the types above as well? Seems like you "fixed" it for the tests by bumping @types/react but that wouldn't fix it for consumers?