Skip to content

Inconsistent type inference when changing the order of type declarationsΒ #55647

Closed
@SimpleCreations

Description

@SimpleCreations

πŸ”Ž Search Terms

N/A β€” this is a very specific case, and I'm not sure which part of the code sample causes the bug.

πŸ•— Version & Regression Information

Tested on all versions starting from 5.0.1. The example repo uses 5.3.0-dev.20230905.

⏯ Playground Link

https://github.com/SimpleCreations/typescipt-compiler-inconsistent-behavior-poc

πŸ’» Code

Steps to reproduce:

  1. Clone the POC repo (see link above)
  2. yarn install
  3. node ./build.mjs

Observe the error listed below in "Actual behavior".

  1. Switch to a branch where order of type declarations is slightly modified (type Footer is moved higher in the file): git checkout modified-type-order; or use the following diff:
diff --git a/src/graphql-types.ts b/src/graphql-types.ts
index 162aab1..cf252dd 100644
--- a/src/graphql-types.ts
+++ b/src/graphql-types.ts
@@ -6,14 +6,14 @@ export type Query = {
   footerCollection?: FooterCollection;
 }
 
-type ExternalLink = Entry & {
-  linkedFrom?: FooterCollection;
-};
-
 export type Footer = Entry & {
   footerLinksGroupCollection?: FooterLinksGroupCollection;
 };
 
+type ExternalLink = Entry & {
+  linkedFrom?: FooterCollection;
+};
+
 type FooterCollection = {
   items: Footer[];
 }
  1. node ./build.mjs

Observe no error.

πŸ™ Actual behavior

  • Incorrectly reported error in the initial example:
src/query.transformer.ts:23:7 - error TS2322: Type 'Footer[] | undefined' is not assignable to type 'FooterTransformer | null | undefined'.
  Property 'field' is missing in type 'Footer[]' but required in type 'FooterTransformer'.

23 const y: FooterTransformer | null | undefined = x;
         ~

  src/query.transformer.ts:9:3
    9   field: unknown;
        ~~~~~
    'field' is declared here.
  • After changing the order of type declarations, the code compiles successfully.
  • In IDEs (e.g. VS Code) you wouldn't see any errors (the types are inferred as expected).

πŸ™‚ Expected behavior

The compiler's behavior is consistent regardless of the order of type declarations. (No error is expected in either case because the types in question are compatible.)

Additional information about the issue

This seems to be a bug somewhere deep down in the TS compiler. It may have something to do with types circularly referencing each other.

There are a few seeming unrelated ways to make the error disappear, e.g. by trying any of the following:

  • Removing Entry & from types;
  • Removing | {} union inside the FooterLinksGroup type;
  • Putting all code into a single file.

All this additionally confirms that this is a compiler bug and not a feature.

This is a bug I encountered in production and tried to reduce the example as much as possible. The need for a build with API instead of the CLI arises from the fact that my original code uses Nest CLI which internally uses the TS compiler API.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions