Skip to content
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

Regression in 4.9: "semantic error TS2312" appears for some interface setups #51559

Closed
sidney-pauly opened this issue Nov 16, 2022 · 4 comments
Closed
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@sidney-pauly
Copy link

sidney-pauly commented Nov 16, 2022

Bug Report

🔎 Search Terms

  • "semantic error TS2312: An interface can only extend an object type or intersection of object types with statically known members"

🕗 Version & Regression Information

  • This changed between versions 4.8.4 and 4.9.3

⏯ Playground Link

Playground link

💻 Code

//

/**
 * The mapping interface that we use to implement interfaces multiple times
 */
export declare type ImplementExplicit<T, TPropertySuffix extends string> = {
    [Property in keyof T as `${Property extends String ? Property : never}_${TPropertySuffix}`]: T[Property];
};

/**
 * The resulting interface that we use elsewhere in the code
 */
export interface I<TSuffix extends string> extends
    MAPD_I<TSuffix>
{
}

/**
 * The type definition that maps the interface "prototype" or template
 * and adds a suffix
 */
export type MAPD_I<TSuffix extends string>  = ImplementExplicit<TMPL_I, `umP47l$_${TSuffix}_$`>;

/**
 * The "prototype" or template of the interface
 */
export interface TMPL_I
{
    Property: string;
}

🙁 Actual behavior

Throws the following error:
semantic error TS2312: An interface can only extend an object type or intersection of object types with statically known members

🙂 Expected behavior

No error just like in previous versions

Remarks

We are using this type of interface pattern to achieve explicit implementations (Like in other languages e.g. c#). I'm aware that this a bit of a hack to get something like this to work in typescript. We do it to be able to replicate data classes that we have written in other languages. The goal is to implement the same interface multiple times. It is useful when the same interfaces is implemented with different generic arguments and thus needs to have the implemented properties multiple times with different types.

E.g. to achieve something like this:

interface SomeInterface<T>{
    property: T
}

class DataClass extends SomeInterface<string>, SomeInterface<number>{
// Impossible to implement as "property" would now collide: i.e. we can't have one version with "string" and one with "number"
}

This is not shown here to have a minimal example that is as simple as possible. The behaviour could be achieved in typescript 3.8.4 by providing a suffix (TSuffix) when implementing an interface (As shown in the example). This suffix gets added to all properties, such that they can exist multiple times on the same object

I'm aware that what we are doing might not be intended to work in the typescript standard, but its in my opinion not acceptable if such behavior changes in a minor version update. In our case npm automatically upgraded the typescript version and all our build scripts suddenly broke.

@sidney-pauly sidney-pauly changed the title Undetected breaking change in 4.9: "semantic error TS2312" appears for some interface setups Regression in 4.9: "semantic error TS2312" appears for some interface setups Nov 16, 2022
@typescript-bot
Copy link
Collaborator

The change between release-4.8 and main occurred at d06a592.

@RyanCavanaugh
Copy link
Member

I'm aware that this a bit of a hack to get something like this to work in typescript.

Indeed, it was a bug that this was ever not flagged as an error. See PR #51050.

Any upgrade, including a patch release, is liable to break code that (even unintentionally) relies on a bug in order to function.

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Nov 17, 2022
@typescript-bot
Copy link
Collaborator

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@muhamedkarajic
Copy link

muhamedkarajic commented Mar 13, 2023

I'm aware that this a bit of a hack to get something like this to work in typescript.

Indeed, it was a bug that this was ever not flagged as an error. See PR #51050.

Any upgrade, including a patch release, is liable to break code that (even unintentionally) relies on a bug in order to function.

Hello @RyanCavanaugh would it be possible to make this optionally somehow possible using a unsafe keyword? We are using generated typescript and have use cases where we want that behavior.

I understand your point of thinking and making typescript more typesafe and robust, but I feel disapointed cause in our case it makes perfect sence to do that and the recent update makes us stuck on typescript 4.8 with a large code base.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

4 participants