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

RFC: Nonstandard tags that should be processed in "Lax" mode #10

Open
aciccarello opened this issue Mar 22, 2018 · 2 comments
Open

RFC: Nonstandard tags that should be processed in "Lax" mode #10

aciccarello opened this issue Mar 22, 2018 · 2 comments
Labels
request for comments A proposed addition to the TSDoc spec

Comments

@aciccarello
Copy link

As the strict mode is defined, what things are important to handle in "Lax" mode?

  • Unique @tags
  • Using @return instead of @returns
  • Using @typeparam instead of @param (I haven't seen this but TypeDoc supports it)
@octogonz octogonz changed the title Lax Mode RFC: Nonstandard tags that should be processed in "Lax" mode Mar 22, 2018
@octogonz octogonz added the request for comments A proposed addition to the TSDoc spec label Mar 22, 2018
@octogonz
Copy link
Collaborator

I'm thinking the criteria should be based on tags that either:

  1. Have useful information that we wouldn't want to lose (e.g. @returns), or
  2. Might cause the comment to be parsed incorrectly if we simply trimmed the tag (e.g. we can safely omit @constructor, but if we omit @throws then what will we do with {InvalidArgumentException} after it?)

IIRC the compiler team approached their implementation empirically, by amassing a large corpus of TypeScript code from GitHub and then analyzing which patterns were most popular. @DanielRosenwasser do you guys have a list of commonly used JSDoc constructs somewhere?

@DanielRosenwasser
Copy link
Member

@aozgaa will have some information here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request for comments A proposed addition to the TSDoc spec
Projects
None yet
Development

No branches or pull requests

3 participants