Thanks to visit codestin.com
Credit goes to github.com

Skip to content

@deprecated nested namespace handling is buggy #59792

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

Open
bradzacher opened this issue Aug 29, 2024 · 2 comments
Open

@deprecated nested namespace handling is buggy #59792

bradzacher opened this issue Aug 29, 2024 · 2 comments
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Milestone

Comments

@bradzacher
Copy link
Contributor

bradzacher commented Aug 29, 2024

πŸ”Ž Search Terms

deprecated nested namespace

πŸ•— Version & Regression Information

  • This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/FAegVGAEACAmCmAHATvAxgQwC71pMIwAdhgLbwDOiGa8kAYgPaMCMAdAEIbKQDewkSPAAeiRsiyQ0jIhUnDIAXkgsA3MAC+wYmUrVaDZuy4AvPgKGjxk6bPlKV6rcCatO3NsPWvjGE5-VtUBAQoJ1yKho6VwAmdzN+QRExCSkZOUgFZTVNbXAoOCRUTBw8AnC9KMNGOK4eRMsUm3T7bKcg2PdkAJdmWr8e7SA

πŸ’» Code

/** @deprecated */
namespace Foo1.Bar {
  export const x = 1;
}

namespace Foo1.Baz {
  export const x = 1;
}

Foo1.Bar.x;
Foo1.Baz.x;
namespace Foo2.Baz {
  export const x = 1;
}

/** @deprecated */
namespace Foo2.Bar {
  export const x = 1;
}


Foo2.Bar.x;
Foo2.Baz.x;

πŸ™ Actual behavior

Usages of Foo1 are stricken through
image

But usages of Foo2 are not stricken through
image

Yet intellisense shows the tag in the hover for Foo2
image

πŸ™‚ Expected behavior

Either both Foo1 and Foo2 should be treated as deprecated, or neither should and instead the Bar in Foo1.Bar and Foo2.Bar should be treated as deprecated.

Additional information about the issue

@typescript-eslint recently released a new lint rule no-deprecated which reports a lint error whenever you use a thing marked with @deprecated.

A user mentioned to us that the rule reports incorrectly in certain cases (typescript-eslint/typescript-eslint#9902).

Specifically in a case like this
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/d1c172bdcfd4508405f4b233e11ccd7d8743f763/types/chrome/index.d.ts#L8553-L8556

We did some investigation and found that things can be pretty ambiguous when nested namespace declarations are marked @deprecated like this and TS itself struggles with it.


It's worth noting that the above behaviour is consistent between nested namespace shorthand (namespace Foo.Bar) and the non-shorthand style

Note you see similar behaviour for many declaration-merged things where TS's handling only makrs something as deprecated if the first definition is marked as deprecated, eg Enums.

But there are also cases where TS gets it right, eg Interfaces

Then there are weird cases like type/value shadowing where I'm not sure if TS is right or wrong -- depends on what you expect I guess.


I would love to see some clarification on what you guys think is the correct behaviour so that we can follow-suit!

@RyanCavanaugh
Copy link
Member

I would love to see some clarification on what you guys think is the correct behaviour so that we can follow-suit!

I have no idea and I don't think it's likely that a poll of developers would produce a strong majority outcome either. It seems much more clarifying to either write

/** @deprecated */
namespace Foo1 {
  export namespace Bar {
    export const x = 1;
  }
}

or

namespace Foo1 {
  /** @deprecated */
  export namespace Bar {
    export const x = 1;
  }
}

depending on which is intended (hopefully they both work more consistently?)

A PR to make them consistent would be fine.

@RyanCavanaugh RyanCavanaugh added Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases labels Aug 30, 2024
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Aug 30, 2024
@bradzacher
Copy link
Contributor Author

Yeah I wasn't sure what the "correct" behaviour should be and I don't think there's a right answer either.

The thing I think that is missing right now is that the order of declarations matters for TS to do its strike through.

I think it'll be worth linting and enforcing against the ambiguity in DefinitelyTyped. I'll raise an issue over there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Projects
None yet
Development

No branches or pull requests

2 participants