syntax-tree / hast-util-to-estree Goto Github PK

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)

Subject

I would like to be able to customize (replacing existing and/or adding more) handlers via options.

Problem

I tried to use this module to parse my hast to estree, but I have something extra in my hast (via raw nodes) I would like to be able to deal with myself. It's easy to copy & paste code here into my project, but it'd be good to be able to leverage this module instead.

Solution

add handlers option in options and merge it with the default one.

Alternatives

Can't think of any good ones.

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.3.2

Link to runnable example

No response

Steps to reproduce

Install the package.

Expected behavior

The package should contain index.d.ts file as described in README and package.json file. Was the build command skipped before releasing the package?

Actual behavior

index.d.ts file is missing.

Affected runtime and version

any

Affected package manager and version

No response

Affected OS and version

No response

Build and bundle tools

No response

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)

Problem

To set up MDX with Solid (e.g. Solid Start), I need to use @mdx-js/rollup which calls @mdx-js/mdx, which uses the rehypeRecma plugin, which calls this util. Then, this util has the element handler which takes care of creating the AST for the JSX elements.

The way it works seems tailored to React in some ways. The two problematic ones I've found are:

• className prop: while it still works in Solid, it's been deprecated and will probably be removed at some point - ref: https://www.solidjs.com/docs/latest#classlist
• style prop: this library turns inline CSS strings into CSS-in-JS syntax, which Solid does understand, but it does so in camel-case. Solid expects the properties to be in their original casing (e.g. background-color not backgroundColor), which makes the output of some rehype plugins incompatible - ref: ref: https://www.solidjs.com/docs/latest#classlist (again 😄)

There might be more instances of this, but I'm not sure.

Solution

I've seen that this library supports configuring the handlers, which is great. However, I have two thoughts about this:

• Replacing the handler for just this one change would mean forking a huge file to replace logic that only spans ~10 lines of code, which is not ideal. Ideally, this would be configurable in a simpler way from within the handler itself.
• This configuration would need to be available all the way up the chain, up to @mdx-js/rollup. I guess it could be a jsxSomething option (jsxFlavor? haha). This util it could have the same option and then it could be passed to the default handlers through the state (I guess? not super familiar so I can't tell if that makes sense).

Alternatives

A solution I've thought of is to create a rehype plugin that "undoes" these changes (e.g. renaming className to class and de-camelcasing the style objects). The problem is that rehypeRecma runs after the external plugins, so there's no way to cleanly execute this.

The only way would be to patch @mdx-js/mdx to introduce the plugin (in core.js), but if I'm patching the package, I might as well just patch this one (element handler) to prevent this from happening in the first place.