Fixes jsdoc generation, adds jsdoc support #512
Conversation
Codecov Report
@@ Coverage Diff @@
## master #512 +/- ##
=======================================
Coverage 84.03% 84.03%
=======================================
Files 47 47
Lines 3801 3801
Branches 869 869
=======================================
Hits 3194 3194
Misses 607 607
Continue to review full report at Codecov.
|
|
Some of the pages have duplicate sections. https://flovilmart.github.io/parse-js-docs-demo/Parse.LiveQueryClient.html |
|
@dplewis yeah I've noticed that as well, I'm not sure what's causing it, and why? |
|
I need to find out why the docs are duplicated... |
|
Other question/ more management wise. Do we keep the api references in each gh-pages or do we move them on the docs repo? |
|
I tried it locally earlier and ran When I removed |
|
@dplewis still is broken, some docs are in double still :/ |
|
@flovilmart I prefer the gh-pages. Looking at the php sdk, gh-pages is far ahead of php docs. |
|
@dplewis it seems that removing those configs did the trick, check again the demo repo, all look good now, some private (_) methods are still missing some docs, but we can live with it. |
|
@flovilmart jsdoc is weird. includes > includePattern. But if the includes doesn't match the includePattern it gets ignored or duplicated. |
|
Yeah I figured the hard way, now the docs look good though! |
|
And it's live! http://parseplatform.org/Parse-SDK-JS/api/1.10.2/ |
|
lgtm! |
|
I need to automate that on release at one point... May not be trivial but we'll see. |
|
we could use that: https://docs.travis-ci.com/user/deployment/pages/ |
|
@montymxb advice on gh-pages deployment? |
|
@dplewis flovilmart is correct, it would be an overriding change. In the case of the php sdk we force gh-pages updates on deploying to the master only. It is a forced change which will overwrite existing changes in gh-pages. Depending on the setup this could be undesirable if you have people adding changes by hand from time to time, as their work could be undone. In our case the entire set of docs is regenerated every time anyways. Automating it as part of a PR merging into master allows the docs to always be up to date as soon as changes are accepted. Just one less thing we have to do that we would be doing anyways, so it makes sense for us there. If it's a similar case here it might be equally useful to do. If anyone is (or will be) adding changes between updates it could be a problem though. Another thing, I put something together over there that ensures that the doc that would be generated for a given PR must be valid. No more accidental missing docs for methods, vars, etc. If doc generation was automated here I would recommend something similar to help ensure a complete doc. |
|
Yep, that’s a good idea, but we loose library versioning :/ |
|
Hmm...if we want to preserve it we can checkout the existing gh-pages, archive the contents in a folder, and then proceed to make our brute-force update. If you did it right you could archive on the releases specifically, and end up with a nice set of folders containing the doc at that point in time. With the forefront docs being the latest set. |
|
That’s what I’m thinking about, i’ll Try to come up with a solution |
This PR fixes a few issues when generating docs with JS docs, See the generated docs here:
https://flovilmart.github.io/parse-js-docs-demo/index.html
If we're all ok with it, I'll push to the gh-pages branch and automate the release on tags.