Try git submobile instead of cloning

[TrySound]

Ref https://git-scm.com/book/en/v2/Git-Tools-Submodules

This fixes micromark to specific commit. I used git checkout 2.10.1
inside submodule and committed result.

At least nothing will break with new changes in micromark.

[ChristianMurphy]

A general question @wooorm why was cloning opted for in the first place?
Could micromark be made an npm dependency?

---

@TrySound can you explain more on the issue you ran into and why this would resolve it?
My experience with submodules is that it tends to be problematic, I'd like to avoid using it if at all possible.

[TrySound]

It's temporary solution for reusing script/babel-transform-constants.mjs plugin in this project. I'm using submodules for the first time and they do not look so scary. At least they allows to easily stick with specific tag.

[TrySound]

I'm changing this logic here micromark/micromark#35 and we need to no break this project.

[wooorm]

@ChristianMurphy because the micromark scripts aren’t published. micromark is already a dependency (from npm), so the GH repo can’t be a dev-dependency (micromark/micromark). Hence, using Git to access the repo and get the script.

[wooorm]

@TrySound What is the reason for doing this?

At least nothing will break with new changes in micromark.

These two projects are pretty tightly coupled and maintained together. And it’s a build step that is tested. So not too worried about it

[TrySound]

Maybe they should be in the same monorepo then?

[ChristianMurphy]

I'm using submodules for the first time and they do not look so scary. At least they allows to easily stick with specific tag.

Getting them setup is the easy part, maintaining them:

• submodules don't automatically get included as part of a standard git clone, --recurse-submodules needs to be added.
• submodules has a lot of cases where they can get detached, usually around pull, checkout or reset causing them to show a being modified when they aren't.
• submodules can get reset on merge conflicts, people have to know to run git submodule update, if they don't any submodule changes will be reset.

because the micromark scripts aren’t published.

What if the scripts were published?

[wooorm]

What if the scripts were published?

Yeah! Especially debug makes sense to be published as it doesn’t relate to mm at all.
For pre-evaluating constants: would be even cooler if it could be generally useful.

For now, they‘re rather specific to this codebase, so I didn’t want to waste an npm package on them — having them in the code was just the easiest.

[TrySound]

I can take care about babel plugins and make them more solid.

[wooorm]

What are your thoughts on making them better?

And are you offering to maintain them yourself? That feels to me like we’re asking too much: I’m assuming they’ll have to be maintained for years; I’m happy to do that

[TrySound]

I'm fine to maintain them too. Will share an access with you. If you wish can transfer to one of your orgs.

[wooorm]

Alright, I’m fine and appreciate you maintaining them, feel free to externalize them! I’d like it if I have somewhat of a say on their heading, because they‘re useful for mm, though. I was thinking of adding them under my personal account instead of a unified org, so having them under your account is just as good!

[wooorm]

How’s that going Bogdan? I’m fine doing it myself!

[TrySound]

Have a bit lack of time. Ok, you can do this. I will add improvements later then.

[wooorm]

Alright, done! thanks for offering to help @TrySound!