My understanding is that in v6 and v7 there are going to be API deprecations. TSDoc decprecations have been already been added for some of these and they are causing some confusion.
For example, in this issue users of the package gained the mistaken impression that of was deprecated and in this issue, the user was unsure of what was deprecated with startWith(null). In both of these situations, the deprecation messages were due to subtleties with TypeScript's signature matching mechanism.
For contributors, it might be obvious what is and what is not deprecated, but it's understandable that users of the package might be confused by deprecation messages that are reported after a patch upgrade - particular when the deprecation message seems to related to 'normal' use.
We could make this somewhat clearer by creating a simple markdown document for each deprecation that lists what is deprecated and why and could add a link to that document in the deprecation message itself. Doing so should not require too much effort and should go some way to curtailing the opening of deprecation-related issues.
@benlesh @JWO719
See also this issue regarding endWith. That user was passing undefined and without strictNullChecks enabled, undefined will match the signature with the Scheduler in it.
I like the idea. If all agree to this approach I can prepare the docs site for this!
I had the same problem with startWith and didn't understand the documentation which was
deprecated startWith( scheduler: SchedulerLike): MonoTypeOperatorFunction<T>
use scheduled and concatAll (e.g. scheduled([[a, b, c], source], scheduler).pipe(concatAll()))
Ended up here to figure out that it's because of the type not getting inferred. Added type like this to solve it startWith(permission.control.value as boolean).
I think the deprecation messages themselves need to be improved. Things like this keep popping up because the messages aren't sufficiently specific: https://stackoverflow.com/questions/56571406/is-the-startwith-operator-in-rxjs-really-deprecated
Also, messages should make sense when presented by a linter - not just when reading the TSDoc. For example, outside of the context of the TSDoc, this might not make much sense:
@deprecated In favor of iif creation function: import { iif } from 'rxjs';
Actually, those messages aren't too bad. TSLint reports them like this:
WARNING: .../source/...ts:29:23 - if is deprecated: In favor of iif creation function: import { iif } from 'rxjs';
Yet another: https://github.com/ReactiveX/rxjs/issues/4918
Hi @cartant !
From what I understand there are the following problems:
current styling
following quick options:
stylishtslint --project tsconfig.json --config tslint.json -t stylish ./index.ts
stylish with links to the docstslint --project tsconfig.json --config tslint.json -s ./formatters -t stylishRxJS ./index.ts
POC can be found here
tools folder that checks if there are deprecations. If yes ad the link.Please let me know your opinion
Unfortunately, I don't think we should use a formatter.
I was not anticipating a solution requiring developers having to adjust their linting configuration and I don't think we can require them to do that.
IMO, it should report understandable messages - that include a URL - without configuration changes.
I would prefer to see a message like this:
ERROR: 3:11 deprecation of is deprecated: passing a scheduler to of is deprecated - see https://rxjs.dev/<whatever>
where passing a scheduler to of is deprecated - see https://rxjs.dev/<whatever> is what would be in the TSDoc.
The of is deprecated part of the message is unavoidable - and unfortunate - so I think the message that follows after that is critical. It has to be succinct and understandable and, IMO, followed by a URL that links to a document with a detailed explanation of the reason for - and the implications of - the deprecation.
I had a look at your answer and a discussion with @JWO719 about the docs part.
I would do the following things:
DeprecationsDeprecations introduced prior to <Version_Number> <Date>JSON format fitting the following structure:[
{
type: 'deprecation' | 'breaking_change'
name: string,
version: string,
date: Date,
implications?: string,
refactoring?: string,
link?: string (link to deprecation or breaking_change depending on type)
}
]
[ ] I use the create list and update manually every deprecation message.
The message has the following sections:
And follows the pattern:
<GenericDeprecationError> <HumanReadebleShortMessage> - see <LinkToDeprecationPage>
Where <HumanReadebleShortMessage> is the section "Reason for depreciation" in the docs/
Here the first draft of the list:
deprecated in 6.0.0-beta.4 (2018-03-29)
deprecated in 6.0.0-rc.0 (2018-03-31)
deprecated in 6.0.0-tactical-rc.1 (2018-04-07)
deprecated in 6.1.0 (2018-05-03)
deprecated in 6.2.0 (2018-05-22)
deprecated in 6.4.0 (2019-01-30)
new Observable()](https://github.com/ReactiveX/rxjs/blob/6.4.0/src/internal/Observable.ts#L53)deprecated in 6.5.0 (2019-04-23)
deprecated in 6.5.1 (2019-04-23)
deprecated in 7.0.0-alpha.0 (2019-09-18)
deprecated in v7.x
removed in v7.x
removed in v8.x
@cartant
I would need a bit of input about the grouping and reverencing them.
I would like to create a timeline that lists all deprecation by release.
If a deprecation gets removed I list the removal and a link to the deprecation with detailed instructions.
What is the best way to discover in which release the deprecation was introduced?
I went through all deprecations and found the version of the introduction.
@benlesh
Please introduce a rule that commits need to mention deprecations!
It took me forever to set up this list. Also, it will take users forever to find out what to do because even in the changelog there is nothing.
Introducing some rules to commit messages and the changelog will help everyone A LOT!
Furthermore, I suggest group similar deprecations within one release. This makes it easier in upgrading versions.
I created a first draft of the deprecation page. I would need some feedback about the content and the linking. Sometimes it is pretty repetitive content, especially in the remove sections.
Also the namings: Removed, Old usage, New usage etc are not really good.
I'm happy for every input. :)
In the following my first try:
never deprecated in favor of constant NEVER| never | Breaking-Change in version 7.x |
| --- | --- |
| Reason | Deprecated because it is more efficient? Some more text here... Some more text here... Some more text here... |
| Implications | Replacing never with NEVER |
Usage <= 6.0.0-beta.3
import { never } from 'rxjs';
never();
Usage >= 6.0.0-beta.4
import { NEVER } from 'rxjs';
NEVER;
empty deprecated in favor of constant EMPTY| empty | Breaking-Change in version 7.x |
| --- | --- |
| Reason | Deprecated because it is more efficient? Some more text here... Some more text here... Some more text here... |
| Implications | Replacing empty with EMPTY |
Usage >= 6.0.0-beta.3
import { empty } from 'rxjs';
empty();
Usage >= 6.0.0-beta.4
import { EMPTY } from 'rxjs';
EMPTY;
never removedDeprecated in version 6.0.0.beta-4 see refactoring suggestions there
empty removedDeprecated in version 6.0.0.beta-4 see refactoring suggestions there
I like it. I think it will resolve a lot of confusion. If figuring out when the deprecations were added it too tedious, I'd suggest a section titled "Deprecations introduced prior to /* some date */".
I updated the draft above and used tables.
Thanks for your feedback and time! <3
I guess I have everything from the content side to start. I will discuss the rest with @JWO719 regarding the integration.
If more feedback pops up, just shoot!
@JWO719 I updated the todos with a JSON structure.
Please confirm it so I can start working on it.
The json structure looks good to me, I could imagine that this could be autogenerated at some point of time!
Exactly this is the reason I want to start with a JSON right away. :)
THX for the answer!