ryedeer/ember-cli-markdown-templates

Support for Markdown templates in Ember-CLI

ember-cli-markdown-templates's Issues

More modular architecture

Hey,

I was wondering if the architecture in here can be a bit more modular in order to support more use-cases. For instance, ec-addon-docs is running their own fork of this code and fixing errors on one project doesn't fix them on another.

On the other hand, I'd like to have the opportunity to write PlantUML in markdown (see ember-learn/ember-cli-addon-docs#399 but not only within ec-addon-docs).

I think both use-cases can be support without ec-addon-docs needing to do anything, but providing a good architecture from this plugin.

Given the nature of marked, there is a couple of things to hook into. E.g. this addon would use the regular lexer but on top would take the token stream and handle handlbars syntax with it (since this is special to ember/glimmer). It would also provide an interface, so other addons can provide their own transformations (on tokenstream, parser or renderer level). For example, I could write an addon, that handles PlantUML. Another addon can be to parse a toc. This information is collected and each consumer (app or addon) can hook into the parsing step (on cli level). For that it will receive an object with all meta information and returns the code it wants to. See my recent addition:

ember-cli-markdown-templates/lib/compile-markdown.js

Lines 57 to 59 in 04535e3

	if (config.format) {
	html = config.format(content);
	}

Now, going back to the original idea, using PlantUML within ec-addon-docs. I would just install it and as a second package would install my PlantUML transformation addon, too. I can achieve my goal and ec-addon-docs is not required to do anything. PlantUML was just an example, yet there can be more for sure.

cc @samselikoff

Optional

Great addon!

What do you think about allowing the user to specify an optional wrapper div and class to be applied to the converted template? This would be useful for styling purposes.