Giter Club home page Giter Club logo

rhai-autodocs's Introduction

rhai-autodocs

Generate Markdown/MDX documentation from a rhai::Engine instance.

Published with Mdbook. generated documentation for mdbook Published with Docusaurus. generated documentation for docusaurus

Features

  • Export native Rust Rhai function and custom types documentation to a simple struct.
  • Generate documentation as Markdown with HTML or MDX, for Mdbook and Docusaurus respectivly.
  • Order functions in your docs with the # rhai-autodocs:index:x directive.
  • Split your docs in 'sections' using the # character in your docs that will be rendered as tabs.
  • Generate glossaries linking to the function definitions.

How to use

use rhai::exported_module;
use rhai::plugin::*;

// 1. Create a plugin module or any kind of Rhai API that supports documentation on functions and types.

/// My own module.
#[export_module]
mod my_module {
    use rhai::plugin::*;

    /// A function that prints to stdout.
    ///
    /// # Args
    ///
    /// * message - append a message to the greeting. (optional)
    ///
    /// # rhai-autodocs:index:1
    #[rhai_fn(global, name = "hello_world")]
    pub fn hello_world_message(message: &str) {
        println!("Hello, World! {message}");
    }

    // NOTE: since this function is an overload of "hello_world", the documentation can
    //       be written once on one of the functions, no need to write it multiple times.
    #[rhai_fn(global, name = "hello_world")]
    pub fn hello_world() {
        println!("Hello, World!");
    }

    /// A function that adds two integers together.
    ///
    /// # rhai-autodocs:index:2
    #[rhai_fn(global)]
    pub fn add(a: rhai::INT, b: rhai::INT) -> rhai::INT {
        a + b
    }

    /// Documentation for functions that do not have the index preprocessor
    /// is ignored.
    #[rhai_fn(global)]
    pub fn dont_care() {
        println!("nope");
    }
}

// 2. Generate the docs with autodocs. This library can be imported as a
//    build dependency into your build script.
//    A typical documentation generation workflow would look like this:

// Specify an environment variable that points to the directory
// where the documentation will be generated.
let docs_path = std::env::var("DOCS_DIR").unwrap_or("target/docs".to_string());

// Create a new engine and register all modules that need to have documentation generated
// for them. In this example, the module defined in the previous code block is registered
// into the engine, but you could register other functions and types ...
let mut engine = rhai::Engine::new();
engine.register_static_module("my_module", exported_module!(my_module).into());

/// Export the documentation as a [`ModuleDocumentation`]. You could stop here and generate
/// you own docs from this structure.
let docs = rhai_autodocs::export::options()
    .include_standard_packages(false)
    .export(&engine)
    .expect("failed to export documentation");

/// Or you could use pre-defined templates for docusaurus or mdbook.
/// Here, documentation is generated for docusaurus with some options.
let mdx = rhai_autodocs::generate::docusaurus()
    .with_slug("/docs/api")
    .generate(&docs)
    .expect("failed to generate mdx for docusaurus");

/// Iterate over the generated documentation for every modules.
for (name, docs) in mdx {
    // Write the documentation in a file, or output to stdout, or anything really.
    println!("docs for module {name}");
    println!("{docs}");
}

For more details, check out the examples folder.

Generating your own documentation

You can pretty much use any templating system to generate documentation. However, this repository already generates documents based on handlebars with the handlebars-rust crate for docusaurus and mdbook. You can check the template folder to get inspired.

rhai-autodocs's People

Contributors

ltabis avatar tired-fox avatar

Stargazers

Jonas avatar Cherry avatar  avatar

Watchers

 avatar

Forkers

tired-fox

rhai-autodocs's Issues

Function order

Some APIs need to have functions in a specific order. It would be great to be able to parameterize the crate to write function signatures in whatever order we want.

If no sections are added then description is ignored

At the end of parsing sections the last section defined is never added to the list of sections.

This causes the last section to be dropped; including the Description section if an additional section is never provided.

Could add a check at the end of the method and if there are lines in a the current_body add it.

if current_body.len() > 0 {
    sections.push(Self {
        name: std::mem::take(&mut current_name),
        body: Item::format_comments(&current_body[..]),
    })
}

rhai-autodocs fails to compile if rhai is using the no_float feature flag

If you use rhai with no_float, then rhai-autodocs doesn't build. Due to feature unification I don't think there is a way around this. Probably rhai-autodocs also need a no_float flag and to disable that float code if rhai is built without it?

error[E0412]: cannot find type `FLOAT` in crate `rhai`
   --> /home/arvid/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rhai-autodocs-0.6.1/src/function.rs:67:53
    |
67  |     let ty = ty.replace(std::any::type_name::<rhai::FLOAT>(), "float");
    |                                                     ^^^^^ not found in `rhai`
    |
note: found an item that was configured out
   --> /home/arvid/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rhai-1.19.0/src/lib.rs:198:10
    |
198 | pub type FLOAT = f64;
    |          ^^^^^
note: found an item that was configured out
   --> /home/arvid/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rhai-1.19.0/src/lib.rs:208:10
    |
208 | pub type FLOAT = f32;
    |          ^^^^^

For more information about this error, try `rustc --explain E0412`.
error: could not compile `rhai-autodocs` (lib) due to 1 previous error

Static order for polymorphed functions

Find a way to order polymorphed functions in order, e. g. using their args, so that generating the documentation multiple times does not produce diffs.

Better asseccibility for module items in mdbook

The mdbook template adds a box shadow to the styling of each items wrapping div. This is fine for light themes, but when darker themes are used it is hard to tell where the start and where the end of these areas are.

Adding a border using the --theme-hover variable for the color adds a separation that matches the current theme and makes the distinction between items more visible.

Here is a screen shot of the styling being applied with the ayu theme.

image

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.