-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Excessive stack depth comparing types with 2.7.1 #21671
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
here is what i am seeing locally: c:\test\21671\typeorm>git remote -v
origin https://github.com/typeorm/typeorm.git (fetch)
origin https://github.com/typeorm/typeorm.git (push)
c:\test\21671\typeorm>git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
c:\test\21671\typeorm>tsc --v
Version 2.7.1
c:\test\21671\typeorm>tsc --diagnostics
Files: 1332
Lines: 117889
Nodes: 572747
Identifiers: 170270
Symbols: 844659
Types: 78716
Memory used: 379295K
I/O read: 0.21s
I/O write: 3.10s
Parse time: 2.87s
Bind time: 0.85s
Check time: 25.98s
Emit time: 10.41s
Total time: 40.11s |
TypeORM users get the error:
where export type DeepPartial<T> = {
[P in keyof T]?: DeepPartial<T[P]>;
}; In TypeORM this is used to check if a given variable is part of the complete entity. At least that's how I understand it. Don't know if that's of any help to you @mhegazy |
do you have a sample i can look at? |
typeorm/typescript-example should give the error if you update it to [email protected] |
Glad I found this issue because I am able to reproduce something similar and I have no idea how some simple types provided by In a brand new project do
Here is some code that works fine: // test.ts
type DeepPartial<T> = { [P in keyof T]?: DeepPartial<T[P]> };
type PayLoad<T> = DeepPartial<T> | DeepPartial<T>[];
interface ISimpleUser {
id: number;
firstName: string;
lastName: string;
}
const payLoadObject:Partial<ISimpleUser> = { id: 0, firstName: 'Leo' };
const payLoadArray: Partial<ISimpleUser>[] = [
{ id: 0, firstName: 'Leo' },
{ id: 1, lastName: 'Austen' },
];
class Endpoint<C> {
post<I = C, O = I>(customPath: string | number, body: PayLoad<I>): void;
post(...args: any[]): void {
console.log(args);
}
}
const endpoint = new Endpoint();
endpoint.post('path', payLoadObject);
endpoint.post('path', payLoadArray);
endpoint.post('path', { id: 0, room: { id: 1, color: 'red' } }); Things work fine:
That should give you no errors. But as soon as we bring in some types:
If we look into the color types we can see that there are two files. The culprit is declare global {
interface String {
strip: string;
stripColors: string;
black: string;
red: string;
green: string;
yellow: string;
blue: string;
magenta: string;
cyan: string;
white: string;
gray: string;
grey: string;
bgBlack: string;
bgRed: string;
bgGreen: string;
bgYellow: string;
bgBlue: string;
bgMagenta: string;
bgCyan: string;
bgWhite: string;
reset: string;
bold: string;
dim: string;
italic: string;
underline: string;
inverse: string;
hidden: string;
strikethrough: string;
rainbow: string;
zebra: string;
america: string;
trap: string;
random: string;
zalgo: string;
}
} If we remove this extension everything works. Any idea why typescript sent me in a wild hunt to see what is wrong with my code? For now I'll have to remove the colors type and hope that no other library interferes. By the way, my IDE is the one that tells me about the excessive stack error. I am not able to see it by using the |
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed. |
Whoa there buddy... I have submitted a reproducible example and a temporary solution I'm using. There is a still an issue here. Any library that messes with the global object will mess typescript. I'm lucky I found out that the colors types was messing up but I don't think I'll find it that easy to find another culprit in the future (or if it would be easy to not depend on it). Can this be looked at please? |
Is this related to #21592? |
I found this issue in the archives as already solved in 2.5. However it seems to appear again: typeorm/typeorm#1544
Any suggestions?
The text was updated successfully, but these errors were encountered: