Skip to content

build: more type information for docs #6947

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

Merged
merged 1 commit into from
Oct 4, 2017

Conversation

devversion
Copy link
Member

@devversion devversion commented Sep 8, 2017

  • Upgrades dgeni and dgeni-packages to the latest available version (including TypeScript support; and newer TypeScript version for AST)
  • More warnings if type information is missing on public TypeScript symbol
  • Adds missing explicit type declarations to all components
  • Types are now being displayed for accessors and properties (this was broken before somehow)
  • Rewrote the Dgeni setup in TypeScript for type safety and better integration into the gulp workflow.

Note: Most of the things inside of the existing Dgeni setup is the same as before and I didn't look into other improvements there (e.g logic simplification) because the PR is big enough already.

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Sep 8, 2017
Copy link
Member

@crisbeto crisbeto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code-wise LGTM, but I'm wondering about how are we going to enforce that we add all the necessary typings?

@@ -94,7 +94,7 @@ export class MdFormField implements AfterViewInit, AfterContentInit, AfterConten

/** @deprecated Use `color` instead. */
@Input()
get dividerColor() { return this.color; }
get dividerColor(): 'primary' | 'accent' | 'warn' { return this.color; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have the ThemePalette type for this already.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I wanted to use that as well, but it also includes undefined as a possible value, which is not valid here.

import {PropertyMemberDoc} from 'dgeni-packages/typescript/api-doc-types/PropertyMemberDoc';
import {MemberDoc} from 'dgeni-packages/typescript/api-doc-types/MemberDoc';

const SELECTOR_BLACKLIST = new Set([
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some inconsistent spacing here.

import {ClassExportDoc} from 'dgeni-packages/typescript/api-doc-types/ClassExportDoc';
import {PropertyMemberDoc} from 'dgeni-packages/typescript/api-doc-types/PropertyMemberDoc';
import {
NormalizedMethodMemberDoc, normalizeMethodParameters
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The normalizeMethodParameters should be on a separate line.

@devversion devversion force-pushed the build/more-type-info-docs branch from 486bc66 to 2d132f9 Compare September 9, 2017 09:11
@devversion
Copy link
Member Author

@crisbeto Addressed your feedback and rebased on top of the sort members commit.

Regarding the enforcement: Good point, I have a TSLint rule in mind. We can base those rules on top of the existing rules like typedef (will be something as a follow-up)

@devversion devversion force-pushed the build/more-type-info-docs branch from 2d132f9 to a97f7f5 Compare September 12, 2017 08:58
@devversion devversion added the P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful label Sep 15, 2017
@devversion devversion force-pushed the build/more-type-info-docs branch 2 times, most recently from 9b70ae2 to 745357e Compare September 22, 2017 14:42
@devversion devversion added P2 The issue is important to a large percentage of users, with a workaround and removed P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful labels Sep 27, 2017
@devversion devversion force-pushed the build/more-type-info-docs branch from 745357e to 861c81d Compare September 29, 2017 12:43
@devversion
Copy link
Member Author

@jelbourn Rebased this one. Please have another look.

@devversion devversion force-pushed the build/more-type-info-docs branch 2 times, most recently from a64eb21 to ae76648 Compare October 1, 2017 08:52

export function isProperty(doc: MemberDoc) {
if (doc instanceof PropertyMemberDoc ||
// The latest Dgeni version no longer treats getters or setters as properties. In theory
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"In theory those" -> "From a user perspective, these"

import {CategorizedPropertyMemberDoc} from '../processors/categorizer';

/**
* Accessors are not parsed properly within the latest dgeni-packages package.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an issue to link for this? What about the accessors isn't parsed correctly?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only reported this on Slack if I recall. Created an issue for it now: angular/dgeni-packages#246

member.kind === SyntaxKind.SetAccessor)
.filter((member: any) => member.name && (member.name as any).text === propertyDoc.name)
.forEach((member: GetAccessorDeclaration|SetAccessorDeclaration) => {
if (member.type) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add comment that explains how you extract the type

classDeclaration.members
.filter((member: any) => member.kind === SyntaxKind.GetAccessor ||
member.kind === SyntaxKind.SetAccessor)
.filter((member: any) => member.name && (member.name as any).text === propertyDoc.name)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If member is any, why do you need to use as any on member.name?

// If the current property document doesn't have any description set and the current
// TypeScript has a symbol from the TypeChecker, we can try to find a documentation
// comment on that symbol.
if (!propertyDoc.description && (member as any).symbol) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you need the as any here, is GetAccessorDeclaration|SetAccessorDeclaration the right type for member?

Copy link
Member Author

@devversion devversion Oct 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is the correct type. It just looks like TypeScript isn't exposing the symbol property in their typings. The same is happening on Dgeni as well (see here)

* Upgrades dgeni and dgeni-packages to the latest available version (including TypeScript support; and newer TypeScript version for AST)
* More warnings if type information is missing on public TypeScript symbol
* Adds missing explicit type declarations to all components
* Types are now being displayed for accessors and properties (this was broken before somehow)
* Rewrote the Dgeni setup in TypeScript for type safety and better integration into the gulp workflow.
@devversion devversion force-pushed the build/more-type-info-docs branch from 66114b9 to 52e4712 Compare October 4, 2017 14:14
@devversion
Copy link
Member Author

@jelbourn Addressed your feedback.

Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jelbourn jelbourn added pr: lgtm action: merge The PR is ready for merge by the caretaker and removed pr: needs review labels Oct 4, 2017
@kara kara merged commit 388845c into angular:master Oct 4, 2017
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement P2 The issue is important to a large percentage of users, with a workaround
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants