Should acornOptions be exposed to @mdx-js/mdx compile?

[EricMCornelius]

Should @mdx-js/mdx compile/evaluate support async top level functions via an option?

Right now, the acorn parsing yields an error for the following:

export const data = await (async () => 1)();

# Data: {data}

Just traced the issue all the way through the mdx dependencies, looks like acornOptions can be injected all the way from @mdx-js/mdx/lib/core.js through remarkMdx

- pipeline.use(remarkMdx)
+ pipeline.use(remarkMdx, {acornOptions: {allowAwaitOutsideFunction: true}})

But there's no exposed option in the @mdx-js/mdx api to actually inject the proper acorn setting.

It's potentially useful as it allows things like asynchronous api calls for initializing data within the mdx documents directly.

[wooorm]

For your use case: I’d recommend against it. The whole module has to wait for an HTTP call while it’s being imported. And the module is only loaded once so the top-level await runs once for your whole app’s lifetime. I think it’d be much better to use your frameworks data loading features to run async work when a component is mounted for example.

Top-level await is useful. But I’d rather switch to a moving target of current JavaScript features rather than exposing all the possible internals. Similar to how we follow latest CommonMark, it’s on 2020 now (also in a couple other places). Not sure what the policy should be when to switch to 2022 (which include TLA)

[EricMCornelius]

For your use case: I’d recommend against it. The whole module has to wait for an HTTP call while it’s being imported. And the module is only loaded once so the top-level await runs once for your whole app’s lifetime

My use case is actually implementing an easy-to-use option for defining headless pdf report generation from arbitrary API data sources - so it's actually precisely what I'm looking for.

I can obviously patch the source though, it's not explicitly an issue. But I was surprised that synchronous functions are accepted in javascript expressions by the parser, whereas async are not, given it's not even truly executing in top-level-await when you use evaluate/run but merely inside the body of an async function.

Obviously this wouldn't work for full program outputs unless the environment supports it.

[wooorm]

What are the negatives I'm not seeing?

Addition in (open source) code is inherently negative if it’s not positive. Especially if it can’t be explained.

Nobody in this discussion has given a use case for passing acornOptions. Only the use case for “allowing modern features” has been discussed, which indeed can be side-stepped. In my experience, side-stepping problems is pretty positive.

[...] other people are bound to want the flexibility to pass other config options to acorn.

Why? For what?

I can't pass props to acorn using a framework's data loading feature.

Why do you want to “pass configuration to acorn with a framework’s data loading features”? Your code seems to read as if it’s displaying the current time. What is the reason for hashing it? Can you perhaps normally display the current time?

[reubn]

Nobody in this discussion has given a use case for passing acornOptions.

I think the use case which is clearly affecting multiple people is using modern language features in MDX. You haven't explain why allowing a single variable to be passed down through config is bad. It's a non breaking change.

The examples I gave were very simple cases to isolate the issue we're discussing.

Your use case for MDX may not require modern language features but mine (and others') do.

Could you explain what the cost to the MDX project would be by passing down this single config object?

Why do you want to “pass configuration to acorn with a framework’s data loading features”?

Sorry, I said this in response to your suggestion that I use a framework's data loading features. I was emphasising that this misses the bigger problem that MDX doesn't allow configuration of the parser.

You said that you're following 2020 at the moment, and also how top level await is part of 2022. If you're planning on adopting 2022 at some point in the future then you'll have to configure this for acorn. All I'm proposing is that the user be able to do this themselves.

[wooorm]

I think the use case which is clearly affecting multiple people is using modern language features in MDX.

That use case can be solved without options.

You haven't explain why allowing a single variable to be passed down through config is bad

Because more options, when they aren’t needed, is bad.

The examples I gave were very simple cases to isolate the issue we're discussing.

I believe you gave one example: hashing a time stamp. I don’t understand this example. I don’t see why it’s wise to display (a hash of) the time when a file was requested.

Could you explain what the cost to the MDX project would be by passing down this single config object?

If there is no use for such an option, then adding code and docs, and maintaining that over time, is a cost.

I said this in response to your suggestion that I use a framework's data loading features

And I said it in response to someone fetching data, when a file is loaded, in a top-level await statement. So there it makes sense to use a framework’s data feature.
Your example displays a hash of the time when a file was requested. I don’t understand that goal.

I was emphasising that this misses the bigger problem that MDX doesn't allow configuration of the parser.

Why is that a big problem? Your use case is about following modern JavaScript features.

If you're planning on adopting 2022 at some point in the future then you'll have to configure this for acorn

Yes. Acorn also has an option for this: https://github.com/acornjs/acorn/tree/master/acorn ("latest").

All I'm proposing is that the user be able to do this themselves.

I understand what you propose. It’s not the only solution to the problem you have. There are different costs attached to solutions. There are trade-offs.

[reubn]

There are different costs attached to solutions. There are trade-offs.

Could you elaborate on the 'cost and trade-offs' of passing a config option to acorn?
I may not be appreciating things from your side.

[wooorm]

Can you instead explain why, as an example:

• You want to put nails in some wood
• You ask for a box of tons of tools to do that
• I propose to give you a hammer
• You don’t want a hammer?

---

Some reasons of why I prefer no options over acornOptions:

• Nobody here needs acornOptions specifically
• Less code is better, because less code is easier to maintain
• Less options and docs are better, it makes this project easier to learn
• Adding something is a minor, removing something is a major, it’s nice to prevent minors
• acornOptions is easy to misuse (e.g., sourceType: true, someone passing onToken), and hard to use
• Users being able to set, e.g., allowHashBang: true, means that MDX the language is less portable, because it can mean different things now
• Defining MDX as supporting latest JavaScript features, similar to latest unicode and latest markdown, is an improvement to the language