Support string arrays like in unified-engine about remark-retext HOT 12 OPEN

Yes, it would be nice, but that would make this project impossible to use in browsers though. And I don’t see a good way around that (other than maybe a browser field, but not perfect?)

from remark-retext.

that would make this project impossible to use in browsers though

Could you expand on why this would break browsers?
Would it make sense/be possible to include a plugin loader on the this context for Plugins, which could abstract the node vs browser differences?

from remark-retext.

I imagine something like this:

unified({
  resolver: (name) => loadPlugin(name, { 'remark' })
})
  .use(remarkRetext, [
    'retext-english',
    'retext-syntax-urls'
  ])

Then unified-engine could define the resolver. In a browser another resolver could be used. The default unified resolver should just throw an error, as it needs to be set explicitly.

The same approach could be used for retext-spell to load dictionaries from a path.

from remark-retext.

I quite like that unified is as small (in size and API surface) as it can be, and this feels... complex.

• remark-retext having to load these plugins at runtime is quite a waterfall (maybe those plugins will in turn also use .resolver, for spelling or for more plugins)
• arbitrary file or network access could result in security vulnerabilities
• rehype plugins would assume plugins with a rehype- prefix are loaded
• Is this just for plugins? For files? Config files? Closest package.json?

from remark-retext.

arbitrary file or network access could result in security vulnerabilities

I'm not sure I follow you you see this being different than the existing top level string based loader.

rehype plugins would assume plugins with a rehype- prefix are loaded

🤔 makes sense, and interesting challenge.

Is this just for plugins? For files? Config files? Closest package.json?

I'd interpret it as being just plugins and presets.

from remark-retext.

I'm not sure I follow you you see this being different than the existing top level string based loader.

Depends on what this can load. If dictionaries, then that seems arbitrary

This also makes configuration complex. The attacher is sync, but as this would operate on options and be async, it introduces a problem: user does .use(a, 'c').use(b), a is async and after a while will configure c after b, which is not what the user thought would happen. Furthermore, the user already called .parse / .run / etc, but c is unexpectedly omitted.

from remark-retext.

Hi! Thanks for taking the time to contribute! This has been marked by a maintainer as needing more info. It’s not clear yet whether this is an issue. Here are a couple tips:

• Spend time framing the issue! The more time you put into it, the more we will
• Often, maintainers respond with why for several back and forths; rubber duck debugging might help avoid that
• Folks posting issues sometimes fall for xy problems: asking for a certain solution instead of raising the root problem

Thanks,
— bb

from remark-retext.

jeez, finally GH fixed there label addition on the API bug. Sorry for all the noise this created though 😅

from remark-retext.

I feel like the added complexity of this, including the headaches around things like endless loading and slow waterfalls, compared to the alternative: use a sharable preset / javascript file where ESM does all that nicely, makes me prefer the latter, current solution?

from remark-retext.