When referenced external dependency contains `.ts` alongside `.js` of the same name, builds are nested

[maschwenk]

Repro case here:

• Repro for weird nesting TS Go does dimitropoulos/tsgo-repros#2

Where a fairly vanilla monorepo setup created a nested dist. Solve-able by just NOT having .ts files in dist (and this is good practice) but it is a weird regression case.

A (very rough) attempt at a fix is here:

• Fix nested dist when referenced package has a .ts file next to a .js file #1214

[jakebailey]

If I'm understanding this correctly, you're saying we're emitting code in the wrong place? As in:

packages/my-package/dist/my-package-b/
packages/my-package/dist/my-package/

Instead of just dist?

If so, the code in #1214 doesn't have anything to do with that; this is probably a bug in the emit code, likely the outputpaths package that determines which files to emit and where.

[DoctorGester]

Same issue as #915?

[jakebailey]

Very likely, yeah

[maschwenk]

@jakebailey yes, though unsure if i'd define it as the "wrong" place versus creating a nesting but could be misunderstanding.

it's not as if my-package-b is putting its output there (the nesting doesn't show up when you run build on package b). it's moreso that my package is seeing the ts in a package it references and then creating a nesting in its dist. so just flattening the nesting alone wouldn't fix it, we shouldn't have any of package-b in there at all.

sorry i may be restating the obvious just clarifying.

[maschwenk]

@jakebailey ill take a look at where that outputPaths code lives

[maschwenk]

#1214 (comment)

Ok so I think the actual issue after chatting on Discord is that isSourceFileFromExternalLibrary is not implemented and not used in sourceFileMayBeEmitted for the Go implementation. That I believe is what would actually exclude these from the emit.

[jakebailey]

All of the code needed to implement isSourceFileFromExternalLibrary is actually there since #1189, actually. We just aren't collecting that list of files.