I believe that the construct name is missing in each package under GFM.

[shlroland]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions

2.0.0

Link to runnable example

No response

Steps to reproduce

source code

Expected behavior

When I want to turn off certain constructs in the parser of remark, such as strong, I can pass attention to disable.null. But when I want to turn off constructs in GFM, such as strikethrough, I have no way unless I stop using remark-gfm altogether and instead selectively incorporate the functions I need.

Actual behavior

Upon examining the code, I discovered that it is this particular line of code that activates the passed disable.null.

    if (construct.name && context.parser.constructs.disable.null.includes(construct.name)) {
            return nok(code)
 }

But in https://github.com/micromark/micromark-extension-gfm-strikethrough/blob/ffa5ca5d0014667ed6c90625037b942cd7761c3c/dev/lib/syntax.js#L38, there isn't a name attribute.

So, would it be more appropriate to include the name attribute?

Relevant
zestedesavoir/zmarkdown#416 (comment)
remarkjs/remark-gfm#34 (comment)
#6 (comment)

Runtime

Node v16

Package manager

pnpm

OS

macOS

Build and bundle tools

Vite

[wooorm]

Hey!

It isn’t exactly an issue: name is optional; it isn’t here because these are extensions, so you should be able to turn them off by not adding them.

But I do welcome PRs, I think it’s nice/good to have: I think I have it on my todolist somewhere too

Closing as this has to be solved in each of the extensions that implement constructs, not in this collection package!

[shlroland]

Hey!

It isn’t exactly an issue: name is optional; it isn’t here because these are extensions, so you should be able to turn them off by not adding them.

But I do welcome PRs, I think it’s nice/good to have: I think I have it on my todolist somewhere too

Closing as this has to be solved in each of the extensions that implement constructs, not in this collection package!

Thank you for your response. This feature is quite important to me, and I will submit PRs.