[Feature Request: to-markdown] support `--features` flag about custom-elements-manifest HOT 8 CLOSED

no

from custom-elements-manifest.

yeah sounds like a good feature, please open a pr

from custom-elements-manifest.

Currently to-markdown doesnt support this, no. It is something we've considered adding before, but we havent got there yet.

What you can do is create a custom plugin, modify/filter the customElementsManifest object to filter out what you want/dont want, and then pass it to customElementsManifestToMarkdown. e.g.:

import { customElementsManifestToMarkdown } from '@custom-elements-manifest/to-markdown';

export function markdown() {
  return {
    name: 'markdown',
    packageLinkPhase({customElementsManifest}) {
      // mutate the cem
      customElementsManifest?.modules?.forEach(mod => {
        mod.declarations = mod?.declarations?.filter(({kind}) => kind === 'class');
      });

      // pass it to markdown
      const md = customElementsManifestToMarkdown(customElementsManifest);

      // write to file somehow
    }
  }
}

I would be down to help if i can, but i'm not that familiar with ASTs and such.

I do agree that the functional approach and all the AST-y stuff isn't really inviting or welcoming for contributions, which is a bit of a shame..

from custom-elements-manifest.

I started working on a PR, relevant code starts here:
https://github.com/michaelwarren1106/custom-elements-manifest/blob/master/packages/to-markdown/index.js#L109

but your comment about the plugin makes me think that I might need to change approach a bit? would you prefer I open a WIP PR for feedback, or are my local repo changes good enough for you to get an idea of where i am headed?

I went down the road of having a config object that has booleans for each section/type of info that can be removed, so that, when false the section isnt rendered. The only struggle Im having right now is telling the difference between the "main class" and super classes, because currently the manifest schema doesnt seem to mark them differently. I have an option currently to remove superClass sections in case those aren't relevant for whatever reason, but the way the nodes get rendered leaves me a bit confused on the best way to check to see if the node i'm about to render belongs to a super class, since i only have kind === 'class' and the superClass property.

from custom-elements-manifest.

PR is also fine, in that case i'll defer to @bennypowers

from custom-elements-manifest.

question: in the manifest.json will the last kind === 'class' declaration always be the "root class"?

from custom-elements-manifest.

will do! i started down one path but i think i have a better idea, so i’m gonna start over.

was struggling with how to remove superclasses but i think i have a config approach that’ll be flexible enough to allow all kinds of final documentation use cases

from custom-elements-manifest.

#139

from custom-elements-manifest.