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

suggestion: expand the functionality of deno doc --lint #23937

Open
iuioiua opened this issue May 21, 2024 · 6 comments
Open

suggestion: expand the functionality of deno doc --lint #23937

iuioiua opened this issue May 21, 2024 · 6 comments
Labels
cli related to cli/ dir suggestion suggestions for new features (yet to be agreed)

Comments

@iuioiua
Copy link
Collaborator

iuioiua commented May 21, 2024

Such as:

  1. Ensure all type parameters are documented with a @typeParam or @template tag.
  2. Ensure all parameters are documented with a @param, @arg, or @argument tag.
  3. Ensure all functions and methods are documented with a @returns tag.
  4. Ensure all symbols have at least one @example tag.

This would significantly improve the quality of package documentation. We currently compensate for this missing functionality in the Standard Library by implementing our own doc checker.

If approved, I'd happily help with these efforts.

CC @dsherret

@iuioiua iuioiua added the suggestion suggestions for new features (yet to be agreed) label May 21, 2024
@iuioiua iuioiua transferred this issue from denoland/deno_std May 22, 2024
@iuioiua
Copy link
Collaborator Author

iuioiua commented May 22, 2024

I talked with @kt3k; he also thinks this might be a good idea.

@dsherret
Copy link
Member

dsherret commented May 22, 2024

I think we might want to consider moving deno doc --lint into the deno lint sub command and only have it active on packages that specify exports. It would be nice to be able to selectively ignore these rules. For example, I don't want to document all these type parameters in deno std:

export function parseArgs<
  TArgs extends Values<
    TBooleans,
    TStrings,
    TCollectable,
    TNegatable,
    TDefaults,
    TAliases
  >,
  TDoubleDash extends boolean | undefined = undefined,
  TBooleans extends BooleanType = undefined,
  TStrings extends StringType = undefined,
  TCollectable extends Collectable = undefined,
  TNegatable extends Negatable = undefined,
  TDefaults extends Record<string, unknown> | undefined = undefined,
  TAliases extends Aliases<TAliasArgNames, TAliasNames> | undefined = undefined,
  TAliasArgNames extends string = string,
  TAliasNames extends string = string,
>(
  args: string[],
  {
    "--": doubleDash = false,
    alias = {} as NonNullable<TAliases>,
    boolean = false,
    default: defaults = {} as TDefaults & Defaults<TBooleans, TStrings>,
    stopEarly = false,
    string = [],
    collect = [],
    negatable = [],
    unknown: unknownFn = (i: string): unknown => i,
  }: ParseOptions<
    TBooleans,
    TStrings,
    TCollectable,
    TNegatable,
    TDefaults,
    TAliases,
    TDoubleDash
  > = {},
): Args<TArgs, TDoubleDash> {

@dsherret
Copy link
Member

I guess being forced to document that isn't so bad now that I think about it more.

@dsherret
Copy link
Member

This will be a bit much though. For example, in some of my projects I wouldn't have time to go through adding examples for everything:

Ensure all symbols have at least one @example tag.

It would be nice to be able to be able to opt-out of certain rules and deno lint provides all that functionality already.

@iuioiua
Copy link
Collaborator Author

iuioiua commented May 22, 2024

I think it's possible deno doc --lint users will be fine without opt-out. The command is opt-in and likely used by those who want the best for their documentation. It might be worth expanding deno doc --lint until we see sufficient evidence of demand for opt-out, which may never come.

@iuioiua
Copy link
Collaborator Author

iuioiua commented May 23, 2024

Perhaps, running code snippets can be done with deno test --doc and the rest with deno doc --lint.

@lucacasonato lucacasonato added the cli related to cli/ dir label Jun 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli related to cli/ dir suggestion suggestions for new features (yet to be agreed)
Projects
None yet
Development

No branches or pull requests

3 participants