Create preset consisting solely of syntax plugins

[SimenB]

Choose one: is this a bug report or feature request?
Feature request

Expected Behavior

When creating tooling, there are multiple reasons to use babel as part of the pipeline. For instance there is an Istanbul plugin for coverage and Jest uses it for mock hoisting.

But since babel has to be able to parse the code in order to make changes to it, features working without Babel present will break when parsed by Babel if the syntax plugins are not present (see istanbuljs/babel-plugin-istanbul#141 and jestjs/jest#4519).

I expect to be able to run Babel on code that parses fine using Node. But just parsing all possible syntax makes sense to me, so that we can apply transformations to the parts we care about without Babel blowing up.

Current Behavior

Syntax error for e.g. Object spread

Possible Solution

A preset containing all syntax plugins. Not sure about stages...

Context

See "Expected Behavior"

Your Environment

software	version(s)
Babel	6.x and 7.x
Babylon
node	8
npm	5
Operating System	macOS

[babel-bot]

Hey @SimenB! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[SimenB]

/cc @bcoe

[hzoo]

Is this preset supposed to be used for tools only? And yeah the issue is about Stage X plugins. Otherwise they would be on by default already (and the only reason why they aren't is because we didn't update v6).

You can already enable syntax via parserOpts too which you can pass to babel-core or @babel/core so I don't think the preset is the only way to do this

[SimenB]

Is this preset supposed to be used for tools only?

Yeah, I don't think just parsing and no transformation makes sense for non-tools, does it?

You can already enable syntax via parserOpts

Then we'd have to manage the syntax modules ourselves, right? Not a terrible burden of course, but not ideal either.

For my use case, just getting the plugins needed to parse whatever the current version of node supports would be enough, that should allow us to avoid the issue with stages, right?

[nicolo-ribaudo]

In Babel 7 you will be able to use babel.parse, which parses the code with the features specified in the .babelrc file. Would it work for your use case?

[SimenB]

Not really. There is no babelrc involved.

We can keep a list of syntax plugins to apply of course, but I was hoping to avoid that source of truth living in Jest

[loganfsmyth]

Is the case here specifically for syntax that has been accepted as stage 4? We should certainly make it parsed by default now since it has landed in stage 4.

Are there cases other than newly-landed official syntax where you'd expect no .babelrc to be present, but Babel would still be expected to parse experimental syntax? It seems like babel.parse would be the right solution since, the user would also need the syntax enabled in their config if they are using it in their code.

[SimenB]

This is specifically for syntax shipping in the currently running version of node (regardless of stage), so the user probably does not have the plugin in their config (if they even have a config, babel is an implementation detail of Jest).

[loganfsmyth]

Gotcha.

I could see an argument for us having a preset like @babel/preset-syntax-node or @babel/plugin-syntax-node or something that would have any syntax plugins that Node supports. I think it would be best to frame the discussion around that. The main question for me then is, is this including stage 3 things that Node has decided to enable before the standard has been accepted? Object rest/spread for instance landed in Node when it was stage 3.

But just parsing all possible syntax makes sense to me

Doing this broadly is something we're unlikely to allow because Babel supports some syntax options that conflict with one-another, so opting into "all possible" is not an option available to us.

[SimenB]

some syntax options that conflict with one-another

Fair enough, let's keep this focused on the node runtime use case then, instead of all syntaxes (syntaxi?).

A preset or a specific plugin sounds great!

I think it'd need to support a target - I don't want it to enable object spread on node 6, for instance. For our purposes we'd say node: current or something like that since we will execute the code later, but I imagine tools like Prettier or something like it just want the parsing, and thus wants to target the newest available.

I think stages - for the purposes of a node-specific thing - should be disregarded. If it ships (unflagged) in Node it should be in, IMO.

I'm sure there will be requests for features behind flags, but at that point I'm willing to say "add the babel plugin yourself" to the users.
But syntax which works out of the box without flags should be supported.

[loganfsmyth]

I think it'd need to support a target - I don't want it to enable object spread on node 6, for instance.

If we're only enabling the syntax plugin, the original code would still be passed through to Node and would throw there. It seems like it would complicate things to have a target on the preset and I'm not convinced it would be much more useful than just opting into anything that the most recent Node supports.

[SimenB]

That's a very good point! The syntax error from babel is prettier than the one from node (and could potentially say "add plugin x to fix it"), but I guess that doesn't really matter :p

[hzoo]

(and could potentially say "add plugin x to fix it"), but I guess that doesn't really matter :p

It should already do this 😄

[SimenB]

This came up again now for BigInt literals which is supported in the latest version of node

[SimenB]

And private class fields 😅

[SimenB]

@nicolo-ribaudo any chance of reviving this? Came up yet again with numeric separators this time

[nicolo-ribaudo]

@SimenB I don't think that it fits in this repository, but I have published https://github.com/nicolo-ribaudo/babel-preset-current-node-syntax.

It detects the features supported by the current Node.js version and enables the corresponding syntax plugins. So far it supports:

• Numeric separators (Stage 3)
• Class public and private fields, and private methods (Stage 3)
• Logical assignment operators (Stage 3) - Not supported by any Node.js version yet.

The following Stage 3 features aren't supported yet because I don't know how to test them, but any suggestion is welcome:

• Top-level await
• import.meta (but it will be enabled by default in the next Babel minor)

What do you think about it?

[SimenB]

Exciting, thanks! Only other I could think of that has caused issues would be bigint literals but that might have been enabled by default already?

Thoughts on plugins enabled by default in newer versions of babel but not in older ones? Just teach users to upgrade their babel version?

[nicolo-ribaudo]

Yes, BigInts are enabled by default since v7.9.0.

Thoughts on plugins enabled by default in newer versions of babel but not in older ones?

I only added features not supported by 7.9.0 (which is the peerDependency on @babel/core for that preset) because if someone wants support for e.g. BigInts they can simply upgrade @babel/core instead of installing this new packages.

Do you think I should target an older version? Maybe 7.8.0 which is 3 months old?

[SimenB]

Aiming for 7.8 sounds good to me 👍 Then we can match that peer dependency in the next version of jest. Our current peer is just 7.0.0

[SimenB]

I've landed that preset in Jest now, so I'll consider this solved (finally!). Thanks!

[SimenB]

And lastly, for anyone following this, Jest 25.3.0 has been released with that preset.

Super happy this is solved now 😀