Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding parserOptions to babel-core transform result #6332

Closed
wants to merge 1 commit into from

Conversation

kesne
Copy link
Contributor

@kesne kesne commented Sep 28, 2017

Q                       A
Patch: Bug Fix? No
Major: Breaking Change? No
Minor: New Feature? Yes
Tests Added/Pass? Not yet
Spec Compliancy? N/A
License MIT
Doc PR No
Any Dependency Changes? No

This adds parserOptions to the transform result from babel-core. The intent here is to be able to run a no-op through babel.transform() and get the resulting babylon options. These could then be used in something like babel-eslint to automatically have it configured based on the result of your babel plugins.

@babel-bot
Copy link
Collaborator

babel-bot commented Sep 28, 2017

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

@loganfsmyth
Copy link
Member

I'm 100% behind enabling the usecase of resolving configs for babel-eslint, but I'd rather we expose a first-class option for it, rather than exposing it through a side-channel of a no-op transformation.

We currently expose loadOptions as part of the primary API, but I think we could pretty easily expose another function that had a similar behavior while exposing the parser options.

@kesne
Copy link
Contributor Author

kesne commented Sep 29, 2017

Yeah I'd love to expose a real way to do this, I can take that route, it just seemed a little difficult because we'd have to re-create some of the logic in the File class.

@ljharb
Copy link
Member

ljharb commented Sep 29, 2017

cc @hzoo; this is related to the babel-eslint stuff we talked about this week :-)

@loganfsmyth
Copy link
Member

I'm going to see if I can expose this in a better way with some refactoring, but I'll report back.

@loganfsmyth
Copy link
Member

What should happen if you run try to lint a file that has been ignored either via .babelignore or .babelrc config? With the current config system, we bail out of config loading as soon as we see that a file is ignored, so there isn't a way to get the config options. We can add a way to do that, but I question how useful that would be.

@ljharb
Copy link
Member

ljharb commented Oct 2, 2017

I would assume either, is treated the same as "env targets + no transforms", or falls back to the default parser, or falls back to ES5.

Ignoring that dir is definitely not that useful; eslintignore should be the only place files can be ignored.

@loganfsmyth
Copy link
Member

Closing since this is making progress in babel/babel-eslint#594

@lock lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Oct 5, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants