Open bradzacher opened 2 weeks ago
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.
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.
🔎 Search Terms
deprecated nested namespace
🕗 Version & Regression Information
⏯ Playground Link
https://www.typescriptlang.org/play/?#code/FAegVGAEACAmCmAHATvAxgQwC71pMIwAdhgLbwDOiGa8kAYgPaMCMAdAEIbKQDewkSPAAeiRsiyQ0jIhUnDIAXkgsA3MAC+wYmUrVaDZuy4AvPgKGjxk6bPlKV6rcCatO3NsPWvjGE5-VtUBAQoJ1yKho6VwAmdzN+QRExCSkZOUgFZTVNbXAoOCRUTBw8AnC9KMNGOK4eRMsUm3T7bKcg2PdkAJdmWr8e7SA
💻 Code
🙁 Actual behavior
Usages of
Foo1
are stricken throughBut usages of
Foo2
are not stricken throughYet intellisense shows the tag in the hover for
Foo2
🙂 Expected behavior
Either both
Foo1
andFoo2
should be treated as deprecated, or neither should and instead theBar
inFoo1.Bar
andFoo2.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 (https://github.com/typescript-eslint/typescript-eslint/issues/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 styleNote 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!