Export @babel/parser#tokTypes in @babel/core

[kaicataldo]

Q	A
Fixed Issues?	Refs https://github.com/babel/babel-eslint/pull/711/files#r231363345
Patch: Bug Fix?	No
Major: Breaking Change?	No
Minor: New Feature?	Yes
Tests Added + Pass?	Yes
Documentation PR Link	N/A
Any Dependency Changes?	No
License	MIT

This exposes @babel/parser in @babel/core, as proposed here. Figured it would be best to just make a PR that we could discuss on :) I wasn't sure if testing deeper than this would be worth it or not, given it would have to change any time @babel/parser's API changes, but happy to update as the team sees fit. Thanks!

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/9471/

[nicolo-ribaudo]

Doesn't babelCore.parse work for your usecase?

[nicolo-ribaudo]

Oh nvm, I saw the babel-eslint pr

[kaicataldo]

@nicolo-ribaudo For the PR I'm working on, all I actually need is babelParser.tokTypes. The idea was first brought up by @loganfsmyth here, but I know a lot has changed since then.

I do think it's weird/confusing to have babelCore.parse and babelCore.parser.parse though 😬

[xtuc]

Missing documentation on the website, but LGTM, thanks

[danez]

We should document it under advanced documentation or not document it in my opinion, because babelCore.parse and babelCore.parser.parse do different things in terms of config, and I could see people getting confused about this.

[loganfsmyth]

Revisiting this after my one-off comment that prompted this, I'm concerned because everything we add to the root by default is exposed in plugins/presets on the api object, and this doesn't seem like something we'd actually want there, especially since we already expose template as the suggested way to create ASTs from code snippets, and parse as a way to parse using the user's config.

I'm not necessarily against this being exported from @babel/core, but I'd want to avoid exposing on api. I do wonder if we'd be better off exporting tokTypes directly instead. I didn't realize until now what tokTypes even was. It's really unfortunate that the tokens array relies on object identity for checking token types :(

[xtuc]

I agree with Logan, and I'm not a big fan of this implicitly exposed API. Would it be possible to change the API to be a fixed object? and then you can expose the parse function.

[kaicataldo]

@xtuc For this PR I actually need access to tokTypes in @babel/parser, but I mainly made this PR because @loganfsmyth had requested it. I'm fine with just closing this and doing what we're doing now. Or would you prefer for me to leave this open as a place of discussion about how we should move forward?

[ljharb]

I would greatly appreciate being able to use the parser in a transform without needing an explicit dependency on it; it would be great to find a way to do that.

[xtuc]

As @ljharb mentioned, exposing the parser in a transform and correctly configured does solve a problem.

I would be in favor of leaving this open for discussion, because we should figure a way to do it I guess.

[kaicataldo]

Actually, seems like an issue would be a better way to track this discussion. At this point, I'm not going to pursue this change since it's not necessary for the babel-eslint PR.

[loganfsmyth]

@kaicataldo Can we just re-export tokTypes on the object for now, and add tokTypes: undefined to

babel/packages/babel-core/src/config/helpers/config-api.js

Line 50 in efa571a

return {

so the value will be overwritten with a blank value? Then we can always go in later to trim down the plugin API.

[kaicataldo]

@loganfsmyth Apologies for the delay - PR updated.