Source code transpiles, but emitted declarations filled with errors

[AnyhowStep]

I apologize if I shouldn't be opening an issue about this.

I asked about debugging long compile times before in another issue, #24435

This issue right now is related to that but in a different way.

The typed-orm project transpiles quickly now, after an unintuitive solution, but the emitted declarations appear "unusable" by other projects (at least according to tsc).

ts-node and VS code don't seem to have a problem with the emitted declarations and seem to run just fine.

---

TypeScript Version: 2.9.1

Search Terms: emit declarations incorrect

Code

import * as o from "typed-orm";
o;

And then run tsc --noEmit --diagnostics

A repo that reproduces the problem can be found here

Expected behavior:

Success after about 17 seconds

Actual behavior:

Errors after about 37s

The list of errors is... Rather large.

---

I have a different project that is using typed-orm and ts-node seems to run it fine. VS code also seems to do some type checking fine (seems to, maybe it skips some more involved checks, or does incremental checking, I have no idea).

However, when I try to run tsc (checking types/transpiling), node just runs out of memory, even after giving it 8GB of RAM.

---

I tried to debug what was wrong. The typed-orm project itself transpiles very quickly, now. I figured there must be something wrong with that project. However, after removing a lot of code, I still got out-of-memory exceptions.

In the end, I created an entirely new project, wrote that snippet above, and saw that even though the source code for typed-orm transpiles, the transpiled declarations seem to have errors.

---

Link to example: here

Link to typed-orm: here

Related Issues: #24435

[AnyhowStep]

I think the problem is around the /expression folder

The source looks like this,

ColumnReferencesUtil.Merge<
    RawExprUtil.UsedReferences<LeftT>,
    RawExprUtil.UsedReferences<RightT>
>

But the emitted declaration that has errors looks like this,

(LeftT extends RawExprUtil.WithParentJoins ? true extends LeftT["data"]["hasParentJoins"] ? LeftT["data"]["parentJoins"][Extract<keyof LeftT["data"]["parentJoins"], "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "10" | "11" | "12" | "13" | "14" | "15" | "16" | "17" | "18" | "19" | "20" | "21" | "22" | "23" | "24" | "25" | "26" | "27" | "28" | "29" | "30">] extends Join<AliasedTable<string, string, import("../column-collection/column-collection").ColumnCollection>, import("../column-collection/column-collection").ColumnCollection, boolean> ? LeftT["data"]["parentJoins"][Extract<keyof LeftT["data"]["parentJoins"], "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "10" | "11" | "12" | "13" | "14" | "15" | "16" | "17" | "18" | "19" | "20" | "21" | "22" | "23" | "24" | "25" | "26" | "27" | "28" | "29" | "30">]["table"] extends AliasedTable<string, string, import("../column-collection/column-collection").ColumnCollection> ? { readonly [tableAlias in LeftT["data"]["parentJoins"][Extract<keyof LeftT["data"]["parentJoins"], "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "10" | "11" | "12" | "13" | "14" | "15" | "16" | "17" | "18" | "19" | "20" | "21" | "22" | "23" | "24" | "25" | "26" | "27" | "28" | "29" | "30">]["table"]["alias"]]: { [index in Extract<keyof LeftT["data"]["parentJoins"], "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "10" | "11" | "12" | "13" | "14" | "15" | "16" | "17" | "18" | "19" | "20" | "21" | "22" | "23" | "24" | "25" | "26" | "27" | "28" | "29" | "30">]: LeftT["data"]["parentJoins"][index] extends Join<AliasedTable<string, string, import("../column-collection/column-collection").ColumnCollection>, import("../column-collection/column-collection").ColumnCollection, boolean> ? LeftT["data"]["parentJoins"][index]["table"]["alias"]
/*snip many, many, many, many, many more lines of code*/

Among the errors,

• "table" cannot be used to index ...
• "alias" cannot be used to index ...
• "nullable" cannot be used to index ...
• "columns" cannot be used to index ...
• "name" cannot be used to index ...
• x does not extend y

I don't know why it's doing the expansion and why it works fine without the expansion but breaks with it.

Is there a way to make tsc not do these expansions that make reading the type difficult?

[AnyhowStep]

I just updated to Version 3.0.0-dev.20180705 and the errors seem different from when I was using 2.9.1 but it's still roughly,

• The typed-orm project itself can run tsc -d without any errors.
• Projects that use the typed-orm project will see lots of errors with the emitted declarations of typed-orm

One of the new types of errors is,

node_modules/typed-orm/dist/src/main/declaration-v2/select-collection/util.d.ts:37199:137 -

error TS2307: Cannot find module 'main/declaration-v2/column-references/column-references'.

37199     } & (Column<string, string, any> | import("main/declaration-v2/column-collection/column-collection").ColumnCollection | AliasedExpr<import("main/declaration-v2/column-references/column-references").PartialColumnReferences, string, string, any>)[];

The directory structure is,

+ typed-orm/
    + src/
        + main/
            + declaration-v2/ (... Don't ask. But it doesn't contain only declarations anymore)
                + column-collection/
                    + index.ts (Exports everything from column-collection.ts and util.ts)
                    + column-collection.ts
                    + util.ts
                + select-collection/
                    + util.ts (One of the many files with the error)

So, main/declaration-v2/select-collection/util.ts is trying to import main/declaration-v2/column-collection/column-collection, but failing, saying it cannot find the module, TS2307

But if I manually fix the emitted declaration by changing it to import ../column-collection or ../column-collection/column-collection, the error goes away, and it can find the module.

[AnyhowStep]

I ran a replace on all the emitted .d.ts files, to change the main/... paths to a relative path.

And it looks like the errors are back to the way they were on 2.9.1, which is,

1. Innocent looking usage of type alias is expanded (Is "expanded" the correct term I'm looking for?)
2. The expansion causes errors like Type X cannot be used to index type Y

[weswigham]

I ran a replace on all the emitted .d.ts files, to change the main/... paths to a relative path.

Looks like we're using the baseUrl to generate a nonrelative specifier, except ofc consumers dont share a baseUrl inside your package. Probably need to ignore baseUrl when generating .d.ts import paths.

Plus the structural decomposition thing.

[weswigham]

Actually, I'm pretty sure those paths are the expected and desired output when baseUrl is set, given that baseUrl is for multiproject/application scenarios (so you say baseUrl is your workspace root, then use nonrelative paths for each workspace folder). Why do you have baseUrl set in your tsconfig; with a quick look I can't find any paths in your application that should rely on it to work?

[AnyhowStep]

I copy-pasted the tsconfig.json from a different project, and never thought about it...

I removed the baseUrl and paths from the tsconfig, ran tsc with 3.0.0-dev 20180706, and the imports are correct.

Sorry about that.

---

In fact, I think the .d.ts outputs of 2.9.1 and 3.0.0-dev 20180706 are identical, now that I've removed baseUrl and paths

[AnyhowStep]

I got it.

AnyhowStep/typed-orm@eecbd43#diff-e4ac64f1d2caf8dc20405612f17c6d62

After so long, I finally got my project to transpile, and have another project successfully use it and transpile, too.

The change is in src/main/declaration-v2/join-collection/util.ts

I basically just spammed Extract<,> where ever necessary.

---

Before, I just had checks like these,

X extends Y ?
    X :
    never

These worked for typed-orm itself, but the generated .d.ts files themselves would expand (decompose?) X and Y, and it somehow led to errors.

My solution is roughly,

X extends Y ?
    Extract<X, Y> :
    never

And it works for typed-orm and projects using typed-orm.
Not the prettiest but... It works.

[weswigham]

These worked for typed-orm itself, but the generated .d.ts files themselves would expand (decompose?) X and Y, and it somehow led to errors.

Yuuuuuuuuuuuuuuuuuuuuuuup. The constraints applied in the true branch by a X extends Y ? X : never won't be maintained if it simplifies to just the true branch, as it likely did in your case. The extra Extract you use gets preserved and maintains the constraints in the emitted types where it would otherwise be erased. We probably need to do something similar when emitting conditional types that got simplified in declaration emit.

[AnyhowStep]

Random question; are these types the same? (They seem to be)

X extends Y ? Extract<X, Y> : never

And

Extract<X, Y>