Skip to content

Add a rudimentary test for @typedef #75

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Jun 24, 2015
Merged

Add a rudimentary test for @typedef #75

merged 1 commit into from
Jun 24, 2015

Conversation

anandthakker
Copy link
Contributor

@tmcw Added this in a super rudimentary format because I needed it for something. Couple of known issues I didn't have time to examine closely: 1) currently needs a @name tag, but presumably the name should be pulled off the @typedef tag (right?), and 2) if the typedef comment is at the end of a file, w/ no subsequent code node, it gets dropped.

@tmcw
Copy link
Member

tmcw commented May 26, 2015

👍 ideally the PR for typedef is in a point release of doctrine before we go live with this

@anandthakker
Copy link
Contributor Author

ideally the PR for typedef is in a point release of doctrine before we go live with this

Sounds good.

@anandthakker
Copy link
Contributor Author

@tmcw Just noticed you forked doctrine into this org. Are you planning to have this module target the fork?

@anandthakker anandthakker force-pushed the basic-typedef-support branch from d37ee30 to 10f7131 Compare June 22, 2015 12:29
@anandthakker
Copy link
Contributor Author

Update: 0d36570 already took care of outputting properties in html. Oddly, just rebased and reverted to previous doctrine release (0.6.4), and this basic @typedef example works just fine... possibly because of 42e8aee.

@anandthakker
Copy link
Contributor Author

^ All of that means that all that's left here in this PR is a test case.

@tmcw
Copy link
Member

tmcw commented Jun 23, 2015

Yeah - it looks like @jfirebaugh already implemented this, or merged part of this branch?

@jfirebaugh
Copy link
Member

42e8aee was the only typedef related change I made.

@anandthakker
Copy link
Contributor Author

Yeah, I think it turned out that 42e8aee, along with actually looking for and rendering @property tags, was the only thing that was strictly needed. (I believe upstream support for @typedef wasn't really necessary because, once @jfirebaugh fixed the name handling, doctrine's default parsing worked fine.)

@anandthakker anandthakker changed the title Add very rudimentary support for @typedef Add a rudimentary test for @typedef Jun 24, 2015
anandthakker added a commit that referenced this pull request Jun 24, 2015
@anandthakker
Merge pull request #75 from anandthakker/basic-typedef-support
c15a2af 
Add a rudimentary test for @typedef
@anandthakker anandthakker merged commit c15a2af into documentationjs:master Jun 24, 2015
@anandthakker anandthakker deleted the basic-typedef-support branch June 24, 2015 22:01
rhendric pushed a commit to rhendric/documentation that referenced this pull request Sep 15, 2022
@hdgarrood
Update kinds, add newer syntaxes, notes (documentationjs#75)
a15f4e6 
* Update kinds

* Pattern guards

* Nested records

Fixes documentationjs#18. Todo: Unify with Records.md?

* Expand section on type synonyms

The example involving `one` did not type check. Now it does. Maybe it would be helpful to think of real-world examples for type synonyms and use those here intead of another example involving Foo & Bar.

* Notes that I would find helpful

* Do something with the bound variable

* Misc. formatting

* Typo, hopefully a bit clearer

* Grammar
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@anandthakker @tmcw @jfirebaugh