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

How to creating and maintaining custom deprecation information and its related deprecations? #23

Closed
6 tasks done
BioPhoton opened this issue Jul 30, 2020 · 0 comments
Closed
6 tasks done

Comments

@BioPhoton
Copy link
Collaborator

BioPhoton commented Jul 30, 2020

  • Add description on how to maintain the generated markdow files in readme.
  • Ensure groupname is a filename format
  • Add formatters
    • tag-based
      • ? upsertheader comment
    • group-based
      • upsert header comment
  • ? More control of maintaining groups
    • ? delete group => should get mentioned and manually delete group in config and group file

The crawler can collect raw technical information regarding a deprecation in a codebase. However, to make the information meaningful to the user we have to provide additional information and maintain that information.

As a minimal set of information, we orientate start with the list @cartant suggested here.

Crawled information:

{
    "version": "branch-name",
    "date": "2020-07-28 21:22:24 +0200",
    "deprecations": [
        {
            "path": "folder-name\\test.ts",
            "lineNumber": 4,
            "name": "variableName",
            "kind": "VariableStatement",
            "code": "const variableName = 0;",
            "deprecationMessage": "// @deprecated variableName",
            "pos": [
                37,
                65
            ],
            "uuid": "1716777346",
            "group": "group-name"
        }
    ]
}

Additional manually generated information:

  • implications
  • refactoring
  • exampleBefore
  • exampleAfter

Possible Single Deprecation Layout:

Deprecations introduced prior to 2018-03-29 (6.0.0-beta.4 )

Static method 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;

Possible Grouped Deprecations Layout:

<!- - ruid--groups

  • 6.0.0-beta.4
    • formattedDeprecationMessage
    • formattedDeprecationMessage
    • formattedDeprecationMessage
  • 6.0.1
    • formattedDeprecationMessage

ruid-groups - ->

Reason Some more text here... Some more text here... Some more text here...
Implications Replacing never with NEVER
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant