Currently, Plans are not being included in the table of contents in the
markdown output. This is because Plans were not being passed to the
table of contents renderer. This adds Plans to the renderer and updates
tests accordingly.
Some variants of markdown do not convert atx-style headers correctly
unless they are surrounded by blank lines. This commit adds blank lines
to increase chances of rendering when using those variants while still
maintaining compatibly with variants that do not require the surrounding
blank lines. Also increases readability when viewing the raw markdown
file.
Currently, if the user is documenting a Puppet 4 type custom function and they try to use the return_type method without also including an @return tag, Strings will throw an error. This is caused by the function handler trying to add a type to a return tag on the function object that doesn't exist. To fix the problem, if you are using return_type, the handler will now add an empty return tag first if one does not exist.
Currently, Puppet Strings only supports Puppet Tasks. Since Plans are
sort of connected to Tasks, it seemed right that Strings should also
support Plans. That and Plans are a thing that needs to be documented.
First, the Puppet[:tasks] setting needs to be set to add the 'plan' keyword to the Puppet Parser's lexicon, so this sets it in the Strings parser if the setting exists. If it does not exist and Puppet.version is less than 5.0.0, Strings will error out.
Second, processing for the Plans themselves is set up. Plans are very
similar to other Puppet objects like defined types and classes, so this
involved some serious copy-pasta.
Third, all the template/to_hash scaffolding for the different outputs is in place (HTML,
JSON, Markdown).
Yey.
Currently, if a user attempts to document the title or name params, Strings will throw a warning saying that these parameters are missing from the class/type. Of course, they aren't, they just may not be explicit. This removes the warning if the param name is 'name' or 'title'.
First, there were some rspec problems we originally connected to directory naming (e.g. 'yard'), but now we think it's a possible bug in rspec (https://github.com/rspec/rspec-core/issues/2184). this removes the markdown_spec.rb test that was both triggering the bug and, as it turns out, is an unnecessary test.
Reverted some of the changes made to the rsapi handler during markdown
output work. Those changes were made because of a typo in the spec
tests, so the typo has been fixed and most of the handler returned to
its original state.
Currently, puppet-strings does not know how to generate documentation
for Puppet Tasks. This does all the work to add support for Tasks
including a new JSON parser, a task handler, task statement, and task code
object. Basically, Strings reads the JSON using the native ruby json
parser and sends values through in a way it understands. It is only
passing json key/value pairs through, nothing is happening with tags at
this time. You can now document Tasks and generate HTML, Markdown, or
JSON output.
The table_of_contents template was already too bulky and redundant and recognizing public and private components was only going to make it worse. This refactors the toc template and the toc class to use a generic outline for all components.
If there is a class, type, or function with no information documented but is pulled in by some fluke or tag we don't support, do not give it its own section
`puppet generate` behavior remains unchanged
`puppet generate --format markdown` now defaults to writing to
REFERENCE.md and will accept an override from --out
`puppet generate --format json` defaults to printing to stdout but will
accept the --out param
This implements the two remaining tags and removes the author tag. Had to do some deeper plumbing because options per function signature were not being passed along from YARD
This implements the author tag. We also claim to support the 'raise' and 'option' tags, but I don't know that we need to. This also consolidates some code in base.rb and adds docs
This makes sure the markdown doesn't include section headers that have no content. e.g. '## Classes' does not get put in if there are no classes. Also, we should deprecate --emit-json and --emit-json-stdout instead of just killing them.
This change does a few things:
1. Fixes up new api handler to return the stuff we want
2. Adds all the logic to parse YARD registries into markdown
3. Adds templates for markdown
4. Changes Face cli to use a --format option that can be used for either
markdown or json
There is a warning that displays when there is no text outside of tags for a given component, this text would become the 'Overview' section. The warning says: `[warn]: Missing documentation for Puppet class 'klass' at (stdin):4` The problem is that if the user has instead used the @summary tag, and is then using only tags, strings will report this warning even though there is clearly documentation. This adds a condition for the warning: If there is no text AND there are no tags, THEN output a warning saying there is no documentation.
In the rake task strings::generate, the arguments json and yard_args
are not applied properly. The logic uses args.key?, however args is not
a Hash but a Rake::TaskArguments (and Enumerable). There is now key?
method.
Use Rake::TaskArguments.has_key? instead.
Prevent mass-changes to files by removing the date in the footer of each page.
Since the generation date isn't particularly useful and isn't tied to either
a git revision or a released version, this could be an easy way to address this
bug. The files will of-course be regenerated but if there are no changes then
the content will be identical and git will not notice.
Because Puppet 4 is typed, parameter type information can
be automatically determined without any explicit documentation
in @param tags. However, users may desire to do so anyway for
consistency. This commit allows @param tags to include a [type]
in Puppet 4 code. Strings will emit a warning if the documented
type does not match the actual type. In such an event, the incorrect
documented type will be ignored in favor of the real one.
This commit adds a new top-level key to the JSON schema for Ruby 3x/4x
puppet functions: `signatures`. This key is an array and is constructed entirely
with data from existing elements of the puppet function object. The data
structure itself remains unchanged, as this commit only affects the final
JSON output for functions.
In the case of a puppet 4x function with multiple dispatches (overloads),
the signatures key is populated with the equivalent of an overload tag
for each which includes the signature and any param or return tags for
the dispatch.
In the case of a puppet function with only one dispatch, the array is
simply populated with a single element containing a lone dispatch
and its param and return tags.
Note that this change does not affect the internal structure or
representation of puppet function objects, but rather only affects
its final display form when serialized into JSON. All prior data
has been left intact, and the only change here is the addition
of the `signatures` member to the JSON output.
Previously, overload objects were not displaying their tags when
they had no docstring text. This was due to an issue in the overload
`to_hash` method, which prevented the tags from being serialized when
the dispatch had no top-level text. This commit updates that logic
so that the tags will always be included in the hash if they exist.
Previously, Strings ignored calls to `return_type` in Puppet 4.x API
function dispatches, preventing the return types of overloads from
being automatically determined. This commit adds a check for a node
with a `return_type` call and handles it properly.
Previously, Strings ignored the return type in Puppet language functions
that used the following syntax:
function foo() >> String {}
This commit updates the FunctionStatement class to use the return
type from such a statement if it exists. In addition, Strings will
now emit a warning if the return type specified in the @return tag
doesn't match the type specified in the function definition.
This commit updates the gh_pages task to reference the SHA
of the branch being documented in the documentation commit.
In addition, the description of each task except `update`
has been removed, as they are not useful on their own and
should be considered private. This is necessary in order
to hide the tasks from the output of `rake -T`.
Previously, YARD would parse ruby strings which used %Q notation
and return the syntax literally. This commit adds a new Util
module with a `scrub_string` method to check for such a string
and remove the errant %Q and %q's.
Previously, due to Jekyll's default rule of not allowing files beginning
with an '_' to be published, the gh_pages rake task led to broken links.
This commit adds a step to the task which adds a _config.yml file to the
`doc` directory of the gh-pages branch which explicitly allows the file
to be published.
Eric Putnam