Skip to content
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

Mission Critical Sprint Ideas #47

Open
leoj3n opened this Issue Aug 30, 2017 · 3 comments

Comments

Projects
None yet
1 participant
@leoj3n
Copy link
Contributor

leoj3n commented Aug 30, 2017

Click β–Ά to expand sections. Note: Order does not necessarily reflect priority.

🐌 Sprint Ideas

[p] = priority, [pts] = difficulty, ❗ = important

πŸ’‘ [3p] Tutorial/presentation on the Tag Stack. [20 pts]


  • Would be an interesting topic.
  • Would warrant some cool animations.

πŸ’‘ [1p] New "plugin" typedef "bit-docs/types/plugin". [8 pts] ❗


  • The bit-docs/types/plugin typedef would be for plugin modules in bit-docs.js.
  • Would explain how the module export is a function that takes a bitDocs object.
    • This object is expected to have a register method.
      • This object with register method might be it's own typedef.

πŸ’‘ [3p] New "plugin" tag "bit-docs-tag-plugin". [15 pts] ❗


  • Would be it's own plugin [bit-docs-tag-plugin].
    • Implements the @plugin tag.
    • Provides a mustache template and any static styles/js.
    • Essentially a namespace for other modules without being a module.
  • Start using @plugin instead of @module for plugin landing page.
    • Makes sense because plugins are expected to follow a certain
      structure. Plugins have bit-docs.js and a subset of groups.
    • Can have special page format for @plugin landing pages because
      a plugin page probably shouldn't be formatted as a module page.

πŸ’‘ [2p] New "copy" tag. [30 pts] ❗


  • @copy ./images/*.{png,jpg}:
    • A tag that copies the matching files to the static destination.
    • Will place asset in subdirectory relative to root to match source location.

πŸ’‘ [2p] Functionality: Finish making bit-docs-process-tags a plugin ❗ [60 pts]


  • Looks like it's half-way done.
    • bit-docs-process-tags is still being required in bit-docs core.

πŸ’‘ [1p] Tags should show up with @ symbol in navigation. [2 pts] ❗


  • IIRC, need to change a template helper called makeTitle or similar.
  • I think it will involve a non-generic hack detecting if name starts with @.
  • Alternative: We could maybe make a new tag similar to @module called @tag.
    • This @tag tag would only be useful for documenting bit-docs core and plugin tags.
    • Would not be meant for public use.

πŸ’‘ [1p] Documenting the siteConfig object. [8 pts] ❗


  • Documenting siteConfig would give users a reference for what is configurable in bit-docs.
    • Most options are configurable in package.json, and most of these options are not documented anywhere yet.
      • Such as:
        • bit-docs.dependencies
        • bit-docs.glob
          • bit-docs.glob.pattern
          • bit-docs.glob.ignore
          • bit-docs.glob.follow
        • bit-docs.parent
        • bit-docs.minifyBuild
        • bit-docs.dest
  • This big/complex configuration object critically affects the entire bit-docs lifecycle.
    • It should probably be documented as @typedef.
  • The siteConfig documentation would live here:

πŸ’‘ [1p] Documenting the bitDocs object. [8 pts] ❗


  • bitDocs is the object passed to the bit-docs.js of bit-docs plugins.
    • Plugins use this object to register hooks.
      module.exports = function(bitDocs){ // <- bitDocs object
        bitDocs.register("tags", tags);
        bitDocs.register("processor", processJavaScript);
      
        bitDocs.register("html", {
          templates: path.join(__dirname, "templates")
        });
      };
  • The bitDocs object would be documented as a new typedef:
    • [bit-docs/docs/types/bit-docs.md]

πŸ’‘ [2p] Ability to bundle demo and sourceref files. [12 pts] ❗


  • Currently the CanJS site for example builds everything into root so that demo files are accessible.
  • It would be better to just copy over the needed files to a dest directory.
  • This would also be extremely useful for the documentCSS people and their Live Style Guide workflow.
  • We will need some API for doing file copying and could be extended as a hook point for build-time modifications.
  • Related: Would putting every demo in separate repos solve this, and actually work?

πŸ’‘ [2p] Guide on Back-End Plugins [9 pts]


  • Front-end half of guide is written, but could probably use some editing.
  • Back-end half of the guide is unwritten:
    • Add it here.
    • [Guide Notes] Back-end plugins are capable of complicated things, like:
      • Fetching files (f.ex: https://github.com/bit-docs/bit-docs-glob-finder).
      • Adding new tags (will have it's own guide).
      • Registering a callback onto some hook.
        • F.ex, front-end plugins like bit-docs-prettify register onto the html hook.
          • JS and Less from the prettify plugin will get flattened to the front-end.
      • Registering a new hook, and subsequently handling that hook.
        • F.ex, bit-docs-generate-html both registers and handles the html hook.
      • Adding support for new file extensions, such as .mustache.

πŸ’‘ [2p] Guide to Publishing to GitHub Pages. [3 pts]



πŸ’‘ [2p] Guide to Creating a New bit-docs Tag. [20 pts]


  • This will be a complicated/involved guide to write.
  • /cc @Macrofig (b/c I think you mentioned working on a Tag guide for DocumentJS).

πŸ’‘ [3p] Hydrate plugin READMEs. [10 pts]


  • Ideally up to par with bit-docs-prettify.
  • Including adjunct files like CONTRIBUTING.md.
  • Could create a Glitch.com remix for each plugin.

πŸ’‘ [3p] New typedef for file processing modules. [5 pts]



πŸ’‘ [3p] Ability to list group items (grouplist/referencedBy). [6 pts]



πŸ’‘ [2p] Ad-hoc theme templates. [15 pts]


  • In the package.json it would be possible to configure a path.
  • This path would point to a directory of templates to be used just like plugins do.
  • These project-level templates would take precedence over plugin and default templates.

πŸ’‘ [3p] Nested signature template. [19 pts]


  • Signatures within signatures.

πŸ’‘ [3p] Ways of overriding plugin default static assets. [25 pts]


  • Primarily thinking about .less files.
    • I think there are ways to control which less files loaded.
  • Might be useful to have a similar thing for templates.

πŸ’¬ Related Topics

πŸ’¬ Topic: New tag @more


  • Could be used in conjunction with most any other Tag.
    • For instance, could use with @description.
    • Would be added on the DocObject.
    • Only text before @more would show in link title attributes.
    • Everything after @more could be exposed in the template as bonus data.

πŸ—£οΈ Answer: [TBD]

πŸ’¬ Topic: Why doesn't processTagsCommand.pop get used?


  • bit-docs-process-tags/types/processTagsCommand documents ['pop', '...'].
    • But it's not actually ever used by and tags in any plugins.
    • poppop is used but not pop.
  • Is it still valid?

πŸ—£οΈ Answer: [TBD]

πŸ’¬ Topic: bit-docs-process-tags/types/tagDataCommand


  • The ['push', {}] command is never used by any tags that I can see.
  • One plugin tag that I expected to be using the push command was [bit-docs-js/tags/codestart].
    • However, it does not use the push command.
    • Instead, it returns a custom object directly.
    • Should this be using the push command?
    • Or is the push command obsolete and it can be removed?
      • Remove push command code and docs in [bit-docs-process-tags/types/tagDataCommand].

πŸ—£οΈ Answer: [TBD]

πŸ’¬ Topic: ProcessorCallback vs ProcessOptions vs ProcessTagsCommand


Rationalizations for naming and organization.

bit-docs
 β€’  types
     β—¦  ProcessorCallback     - b/c callback lives in [bit-docs/lib/process/file] and is passed to multiple processors ([bit-docs-js/process/code] vs [bit-docs-process-tags/process-tags]).
                              - Is used recursively in [bit-docs-js/process/javascript] and [bit-docs-js/process/codeAndComment].
                              - [bit-docs-process-mustache/process-mustache] uses this callback format without doing anything with [bit-docs-process-tags].

bit-docs-process-tags
 β€’  types
     β—¦  ProcessOptions        - b/c `tags` working depends on this plugin/package being included/required. Maybe change in future? /cc Justin
                              - Currently `siteConfig.tags` will exist as `tags` on the object passed to every processor, even without [bit-docs-process-tags] as a plugin.
                                - The `bit-docs.js` is a dummy.
                                - Tags always get processed because [bit-docs/lib/process/file] hard requires [bit-docs-process-tags]
                              - `tags` on `siteConfig` is closely bound to core.
                              - Registering on the `tags` hook is something ~60-70% of the plugins do.
                              - tags always get processed
     β—¦  ProcessTagsCommand    - b/c commands are specific to the tag stack which is entirely a [bit-docs-process-tags] paradigm.

πŸ—£οΈ Answer: [TBD]

πŸ’¬ Topic: New terminology "comment" rename to "block"


  • For example, this:
    processTags({
      comment: source,
      docMap: docMap,
      scope: scope,
      docObject: {src: {path: filename}},
      tags: siteConfig.tags
    }, addToDocMap);
  • Would become:
    processTags({
      block: source,
      docMap: docMap,
      scope: scope,
      docObject: {src: {path: filename}},
      tags: siteConfig.tags
    }, addToDocMap);
  • Where a "block" is a "doc block". In .js files this is from /** to */.
  • Markdown files are treated as one big "doc block" or just "block".
  • ALTERNATIVE (I like this): [bit-docs/types/tag] block or "Tag block".
  • Makes sense because a Tag block means either...
    • ...from /** until */ or...
    • ...an entire file like .md that is one giant block of @ tags.
    • Should there be a @typedef TagBlock?
      • Page would explain this concept.
      • [bit-docs/types/TagBlock] will be used as the type for the param passed [bit-docs-process-tags/types/processOptions] as comment
      • Currently only [bit-docs-js] has a processor that breaks file source into discreet TagBlocks.
        • Breaking up blocks happens in [bit-docs-js/process/javascript.js]
          • Uses [bit-docs-js/process/get_comments.js]
            • Should become get_blocks.
      • Treats .md as one big TagBlock (doesn't try to break up blocks or interpret code):
        • [bit-docs-process-tags]
          • Looks into the passed TagBlock (options.comment) and finds lines starting with @.
      • Treats .mustache as pure FileSource:
        • [bit-docs-process-mustache]

πŸ—£οΈ Answer: [TBD]

πŸ’¬ Topic: Any way to document argument sets?


  • For example, consider:
    • function funcA(a, b, c, d) {}
    • function funcB(a, b, c, d) {}
    • function funcC(a, b, c, d) {}
  • Is there a way to document a, b, c, d as a typedef?
  • Or should code be refactored to use options object?

πŸ—£οΈ Answer: [TBD]

πŸ’¬ Topic: Unknown type "{?}" throws error


  • We should support this or remove docs on it.
    • Docs are in bit-docs-type-annotate/types/typeExpression.
  • Similar to any type {*} which works fine.

πŸ—£οΈ Answer: [TBD]

πŸ’¬ Topic: Use of "..."


  • Watching people follow the StealJS training, they got confused by what was meant by ....
    • The ... is used in JSON objects to denote redacted key/value pairs.
    • There might be a better way to collapse or redact this information for the guides, etc.
  • Quick fixes:
    • Without adding new functionality, just use a more obvious placeholder, like:
      • [...] or
      • ---snip--- (I like this one)

πŸ—£οΈ Answer: [TBD]

πŸ’¬ Topic: html.staticDist


  • Would be useful if a plugin later in deps can overwrite static assets of another.

πŸ—£οΈ Answer: [TBD]

πŸ’¬ Topic: Template Artifacts.


  • Extra <p></p> at end of div.returns.
  • Returns {undefined}: ... <- Template prints "undefined" return type.
  • Strange .html file in bit-docs-site default.
  • Drop : if there is no description text to follow.
    • Problem exemplified in these docs.
    • docMap {DocMap}: ...and then nothing follows.
    • When there is nothing to follow, drop : and we're good.

πŸ—£οΈ Answer: [TBD]

πŸ’¬ Topic: Capital vs lowercase?


  • {String} vs {string}
  • {Function} vs {function}

πŸ—£οΈ Answer: Capitalize when using types like {Function}.

πŸ’¬ Topic: Regarding the description tag.


  • Should we always specify @description, for every file, for consistency?
    • Currently some files don't have @description and are missing @body.
  • @description should only show first sentence in link title?
    • Some descriptions are long with multiple lines.
    • Titles of links to such pages use the @description and it can get pretty verbose.
  • Links in @description use name, but could be resolving title. For example:
    • [bit-docs/types/docObject] from @description in a link title becomes "docObject".
    • Resolving to get title instead of name, link title would be "DocObject" (big D).

πŸ—£οΈ Answer: Yes, we should always explicitly specify @description.

πŸ’¬ Topic: TOC header links have no matching ID.


  • Therefore, the anchor links don't work.
  • Should we add IDs to the HTML header elements?
  • If so, should it be in the generated output or added onload using JavaScript?
  • More info at the issue for this: bit-docs/bit-docs-html-toc#23

πŸ—£οΈ Answer: This DOES need to be fixed; should work out of the box.

πŸ’¬ Topic: Should typedef file names be capitalized?


  • Their titles are capitalized in the docs.
  • Currently, the files are camelCase.

πŸ—£οΈ Answer: No! They should not be camelCase either; they should be dash-separated.

πŸ’¬ Topic: What about this reference to documentjs-ignore?



πŸ—£οΈ Answer: This can probably be safely removed.

πŸ’¬ Topic: Optional nature of parameters not reflected in templates.


  • Examples:
  • Question:
    • Should the optional character identifiers [ and ] be reflected in the template? If so, how?
  • Analysis:
    • It looks like the problem is in how the template currently renders.
    • The template has access to an optional boolean when then @param is optional:
      • docObject.signatures[0].params[3].optional
      • Equals true, or doesn't exist if not optional.
    • In the old CanJS docs, the template did print the word "optional" in the upper right of the parameter <li/>:

πŸ—£οΈ Answer: This DOES need to be fixed; one solution might be to add back the [ ] syntax in the theme template when optional key is set.

πŸ’¬ Topic: When documenting exports, should we prefix with likely module variable name?



πŸ—£οΈ Answer: Not necessary to prefix with "likely variable name"; assume module is used solo.

πŸ“š Interesting Facts

  • βœ… Can you have multiple @module declarations in one JS file? Yes.
  • βœ… Can you have multiple @signature declarations? Yes.
  • ❌ Can one child have multiple parents? No.
@leoj3n

This comment has been minimized.

Copy link
Contributor Author

leoj3n commented Sep 1, 2017

🚨 Merge Tracker

⁉️ click for explanation

Summarizes important changes across bit-docs Plugin Repos made per major Pull Request organized using a bespoke concept of Groups and Symbols.

Plugin Repos

Repositories are under the bit-docs org:

Pull Request

Each 🌲PR branch of a plugin repo can be summarized as having πŸ”€changes and/or πŸ†•additions to documentation organized by πŸ—‚οΈgroup, as well as new πŸ’₯ functionality, using the following format:

  • 🌲 [1p] branch [5 pts] ❗
    • πŸ”€ bit-docs.js (note: this is always the plugin landing page / main parent)
    • πŸ—‚οΈ tags
      • πŸ†• tags/my.md @my
    • πŸ—‚οΈ types
      • πŸ”€ types/myType.md MyType
    • πŸ—‚οΈ static
      • πŸ†• my.less
      • πŸ†• my.js
    • πŸ’₯ functionality
      • Any change/addition notes not related to documentation.

This format is replicated for each major PR branch.

Groups

A typical bit-docs plugin organizes the documentation for itself as follows:

  • πŸ—‚οΈ modules
    • Pages documenting an actual .js module.
  • πŸ—‚οΈ tags
    • Pages documenting a documentation @ tag.
  • πŸ—‚οΈ types
  • πŸ—‚οΈ static
    • Pages documenting a static asset (like .less).
  • πŸ—‚οΈ templates
    • Pages documenting a .mustache template.
  • πŸ—‚οΈ generated
    • Pages documenting a generated directory or file.
    • Only really used by a generation plugin like bit-docs-generate-html.

Such groups will be rendered as sections within the navigation sidebar of the generated website:

image

Symbols

Meaning of symbols used herein:

= has branches/PRs that could potentially break backwards compatibility

🌲 = PR branch, πŸ—‚οΈ = group, [p] = priority, [pts] = difficulty, ❗ = important

πŸ†• = doc additions, πŸ”€ = doc changes

πŸ’₯ functionality = group for listing changes to code / anything except docs

strikethrough = merged


πŸ“¦ bit-docs-generate-html

Generates a static html site given a docMap

Pulls for bit-docs-generate-html:

  • 🌲 [1p] flexbox-rework #36 [20 pts] ❗
    • πŸ”€ bit-docs.js
    • πŸ—‚οΈ static
      • πŸ†• site/default/static/styles/mixins.less
      • πŸ†• site/default/static/styles/styles.less
      • πŸ†• site/default/static/styles/variables.less
    • πŸ—‚οΈ templates
      • πŸ†• site/default/templates/content.mustache.md
      • πŸ†• site/default/templates/templates.md
    • πŸ’₯ functionality
      • New flexbox code in mixins.less, styles.less, and variables.less
  • 🌲 [1p] docs #38 [50 pts] ❗ (depends on flexbox-rework)
    • πŸ”€ bit-docs.js
    • πŸ†• site/default/default.md
    • πŸ—‚οΈ modules
      • πŸ†• build/build.js
      • πŸ†• build/build_hash.js
      • πŸ†• build/helpers.js
      • πŸ”€ build/make_default_helpers.js
      • πŸ”€ build/renderer.js
      • πŸ”€ build/static_dist.js
      • πŸ†• build/templates.js
      • πŸ†• generate.js
      • πŸ†• html.js
      • πŸ†• write/doc_map.js
      • πŸ†• write/doc_object.js
      • πŸ†• write/search_map.js
      • πŸ†• write/static_dist.js
      • πŸ†• write/write.js
    • πŸ—‚οΈ static
      • πŸ†• site/default/static/build.html.md
      • πŸ†• site/default/static/build.js
      • πŸ†• site/default/static/package.json.md
      • πŸ†• site/default/static/packages.js
      • πŸ†• site/default/static/static.js
      • πŸ†• site/default/static/static.md
      • πŸ†• site/default/static/styles/mixins.less
      • πŸ†• site/default/static/styles/styles.less
      • πŸ†• site/default/static/styles/variables.less
    • πŸ—‚οΈ templates
      • πŸ†• site/default/templates/body.mustache.md
      • πŸ†• site/default/templates/content.mustache
      • πŸ†• site/default/templates/content.mustache.md
      • πŸ†• site/default/templates/description.mustache.md
      • πŸ†• site/default/templates/footer.mustache.md
      • πŸ†• site/default/templates/header.mustache.md
      • πŸ†• site/default/templates/layout.mustache.md
      • πŸ†• site/default/templates/menu.mustache.md
      • πŸ†• site/default/templates/sidebar.mustache.md
      • πŸ†• site/default/templates/templates.md
      • πŸ†• site/default/templates/title.mustache.md
    • πŸ—‚οΈ generated
      • πŸ†• site/generated/static/build/build.html.md
      • πŸ†• site/generated/static/build/build.js.md
      • πŸ†• site/generated/static/build/buildHash.md
      • πŸ†• site/generated/static/build/dist.md
      • πŸ†• site/generated/static/build/package.json.md
      • πŸ†• site/generated/static/build/packages.js.md
      • πŸ†• site/generated/static/build/static.js.md
      • πŸ†• site/generated/static/build/styles.md
      • πŸ†• site/generated/static/dist/buildHash.md
      • πŸ†• site/generated/static/dist/static.css.md
      • πŸ†• site/generated/static/dist/static.js.md
      • πŸ†• site/generated/static/dist/steal.production.js.md
      • πŸ†• site/generated/templates/buildHash.md
    • πŸ—‚οΈ types
      • πŸ†• types/builder.md Builder
      • πŸ†• types/make_helpers.md MakeHelpers
      • πŸ†• types/renderer.md Renderer
    • πŸ’₯ functionality
      • Increase timer time in html_test.js
      • Add deps to package.json
        • q@^1.5.0
        • steal-tools@1.X
      • πŸ”€ site/default/static/package.json
        • steal@1.X
        • steal-less@1.X
        • steal.plugins config
      • site/default/templates/layout.mustache
        • {{pathToDest}}/static/node_modules/steal/steal.production.js => {{pathToDest}}/static/steal.production.js
          • New location for steal 1.X file.
      • πŸ”€ site/default/templates/title.mustache
        • Wrap type in <code/>.
  • 🌲 [1p] new-functionality #47 [9 pts] ❗ (depends on flexbox-rework)
    • πŸ’₯ functionality
      • Collapse paragraph tag in certain cases
      • Set viewport meta for mobile devices
      • Add link to Home in menu navigation template
      • Existence check in string output
      • NOTE: This branch integrates signature template from bit-docs-js.
        • Might want to back out to keep default template generic.


πŸ“¦ bit-docs-glob-finder

Bit-docs default finder that uses glob patterns

Pulls for bit-docs-glob-finder:

  • 🌲 [1p] docs #5 [8 pts]
    • πŸ”€ bit-docs.js
    • πŸ—‚οΈ modules
      • πŸ†• index.js
    • πŸ—‚οΈ types
      • πŸ†• types/globObject.md GlobObject
  • 🌲 [3p] warn-symbolic-glob #4 [5 pts]
    • πŸ’₯ functionality
      • Gives a warning when symbolic directory detected.


Β Β bit-docs-html-highlight-line

Adds a @highlight tag. Needs to be used after bit-docs-prettify.

Pulls for bit-docs-html-highlight-line:

  • 🌲 [1p] docs #7 [6 pts]
    • πŸ”€ bit-docs.js
    • πŸ—‚οΈ tags
      • πŸ†• tags.js @highlight
    • πŸ—‚οΈ static
      • πŸ†• highlight-line.js
  • 🌲 [3p] static-asset #6 [7 pts]
    • πŸ—‚οΈ static
      • πŸ†• static/styles/highlight-line.less
    • πŸ’₯ functionality
      • New file: ./static/styles/highlight-line.less (with article code β‡… EXPAND β‡…)
      • Renames highlight-line.js to index.js and updates package.json
      • Updates file index.js to require highlight-line.less.
      • ASIDE: Goal/idea of this is that the plugin should encapsulate basic necessary styles.
        • Currently this code is hidden away inside CanJS and DoneJS themes.
        • This provides default styling that can be overwritten.


πŸ“¦ bit-docs-html-toc

A table of contents for your documentation

Pulls for bit-docs-html-toc:

  • 🌲 [1p] docs #24 [6 pts]
    • πŸ”€ bit-docs.js
    • πŸ—‚οΈ tags
      • πŸ†• tags.js @outline
    • πŸ—‚οΈ static
      • πŸ†• toc.js


Β Β bit-docs-js

A collection of tags, templates, and basic styles for JavaScript applications.

Pulls for bit-docs-js:

  • 🌲 [1p] signature-template #10 [20 pts] ❗
    • πŸ”€ bit-docs.js
    • πŸ—‚οΈ static
      • πŸ†• index.js
      • πŸ†• static/styles/signature.less
    • πŸ’₯ functionality
      • Add basics for signature template.
        • Create templates/helpers.js
        • Create templates/signature.mustache
        • Including front-end styles
          • Modify bit-docs.js to add to dependencies object
          • Create main file index.js that requires style file
          • Create style file static/styles/signature.less
            • Note this static/styles organization can be used for any/all static files.
            • Organize other plugins like this? (prettify.less, highlight-line.less).
  • 🌲 [1p] docs #11 [25 pts] ❗
    • πŸ”€ bit-docs.js
    • πŸ—‚οΈ modules
      • πŸ†• process/code.js
      • πŸ†• process/code_and_comment.js
    • πŸ—‚οΈ tags
      • πŸ†• tags/class.js @class
      • πŸ†• tags/codeend.js @codeend
      • πŸ†• tags/codestart.js @codestart
      • πŸ†• tags/constructor.js @constructor
      • πŸ”€ tags/function.js @function
      • πŸ†• tags/module.md @module
      • πŸ”€ tags/option.js @option
      • πŸ”€ tags/param.js @param
      • πŸ†• tags/property.js @property
      • πŸ†• tags/prototype.js @prototype
      • πŸ†• tags/return.js @return
      • πŸ”€ tags/signature.js @signature
      • πŸ†• tags/static.js @static
      • πŸ†• tags/typedef.js @typedef
    • πŸ—‚οΈ templates
      • πŸ†• templates/signature.mustache.md


Β Β bit-docs-prettify

A bit-docs plugin that makes source-code snippets in HTML prettier.

Pulls for bit-docs-prettify:

  • 🌲 [1p] remove-dead-code #10 [16 pts] ❗
    • πŸ—‚οΈ static
      • πŸ†• prettify.less
      • πŸ†• prettify-variables.less
    • πŸ’₯ functionality
      • Clean up prettify.less.
        • Import prettify-variables.less.
        • Allow user theme to override variables.
      • New file: prettify-variables.less.
      • Add prettyprint className to parent node.
  • 🌲 [3p] docs #11 [8 pts] (depends on remove-dead-code)
    • πŸ”€ bit-docs.js
    • πŸ—‚οΈ static
      • πŸ†• prettify.js
      • πŸ”€ prettify.less


πŸ“¦ bit-docs-type-annotate

Utilities for parsing closure type annotations.

Pulls for bit-docs-type-annotate:

  • 🌲 [1p] docs #2 [14 pts] ❗
    • πŸ—‚οΈ types
      • πŸ†• types/type_data.md typeData
      • πŸ†• types/value_data.md valueData
      • πŸ†• lib/namer.js NAME-EXPRESSION
      • πŸ†• types/typeExpression.md TYPE-EXPRESSION


πŸ’― Merge Results

Final summary about what was merged:

  • πŸ“¦ 7 bit-docs plugin repos
  • 🌲 13 merged PR branches
  • πŸ†• 87 documentation additions
  • πŸ”€ 23 documentation modifications
  • πŸ’₯ 6 PR branches affected functionality
@leoj3n

This comment has been minimized.

Copy link
Contributor Author

leoj3n commented Oct 23, 2018

πŸ‘€ Outstanding Issues

What to πŸ‘ Merge, πŸ‘Ž Delete, 🎱 Create, and πŸ”Ž Read.

πŸ‘ Core

πŸ‘ Fixes

πŸ‘Ž Unused

🎱 Future

πŸ”Ž Unresolved

❓ Redesign

@leoj3n

This comment has been minimized.

Copy link
Contributor Author

leoj3n commented Oct 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.