micromark and remark-admonitions

[mmsinclair]

@wooorm starting a new discussion from elviswolcott/remark-admonitions#27 here

I've copied the structure of the repos and code from https://github.com/micromark/micromark-extension-directive. For the most part I was creating a blend of fenced code and directives. The admonitions are very similar to directives.

The packages I have are:

mdast-util-admonition
micromark-extension-admonition
remark-admonition

The outstanding work that needs doing is:

• Re-work what I've done to use new code style (I prefer import/export over require style and I'd like to use newer features like spreading although happy to do it another way to keep compatibility consistent with other parts of micromark/remark)
• Add more tests to meet code coverage requirements
• Review and rework
• Make repositories public
• Setup builds and publishing

I have a couple of questions:

1. Where are these packages going to go on Github?

I feel they should be part of @unifiedjs because they can be community owned and maintained. And the GitHub orgs they are in should reflect this. Suggestions/comments?

Currently I have them in a monorepo, although they could easily go into separate repositories. I always feel managing issues on separate repositories is much better in Github, however, because the three packages are so tightly coupled, they are likely to move in lock step, so a monorepo is easy to use. Do you have a preference?

How do new repositories get added to the micromark and remarkjs orgs?

2. Initial review

I'd really appreciate some review on what I have done. And I'm thinking the easiest way to do this would be in a monorepo in my personal GitHub account. And after some rework, it could go to its final home?

Also happy to go for the destination repositories from the start and work directly from there if that makes any sense.

Please suggest what would be most convenient for you.

3. CI/CD and publishing

I can easily adjust what is in the directives repositories for builds - how would I go about testing that it all works?

[wooorm]

👋

Re-work what I've done to use new code style (I prefer import/export over require style and I'd like to use newer features like spreading although happy to do it another way to keep compatibility consistent with other parts of micromark/remark)

See unifiedjs/unified#121 for more info on ESM. I’m soon going through unified, then retext/remark/rehype should be straightforward. Should be done at the end of July.

1. Where are these packages going to go on Github?

Read more about unified here: https://github.com/unifiedjs/collective. Particularly, the organizations policy for whether projects make sense inside or outside the collective: it’s fine to maintain things outside of the collective! See also the members policy on whether you’d want to become a member of one or more orgs and help triage or maintain things.

If they’re maintained outside the collective, a monorepo will work fine I think (and you’ll have more choices for what code style and tools you want to use). If they’re inside, they’d be split over several organizations, and it’s important that things style and tools fit with the rest.

2. Initial review

Happy to review! Depends on point 1.

If there is copy that is copy/pasted from micromark-extension-directive (e.g., how to parse HTML attributes), it might be good to expose that by turning micromark-extension-directive into a small monorepo with that code, rather than copy/pasting everything. A similar example is micromark-extension-mdx-expression, which has some functionality also needed by other MDX parsing extensions.

3. CI/CD and publishing

We have releasers teams per org that are in charge of manually releasing things. CI should “just work” if you fork as it runs on GH Actions.