Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Create an empty directory and do this:
I've thought about this and it doesn't make any sense. The behaviour of the CLI flags and API options are fundamentally different. Making an API option produce source maps on disk is very different to just populating a property. I'm going to close this as a wontfix.
@sebmck, I just wasted half an hour reproducing this. I might not be the only one. Reading this thread, I'm now worried there might be //other// options
Maybe, you can wallpaper over this one with a documentation fix. I doubt it. The presence of
Also, consider the case of
I can write my own command line for
I am also surprised by this implementation decision.
I just had to double-check to make sure that the documentation does not explicitly state
I would be a very good idea to clarify in the Babel Options documentation which
Then why have an rc file when you're not going to follow *nix philosophy?
I'm quite confused by this as well..
The babel cli will use the .babelrc to configure itself, but ignores specific "API Only" configuration parameters? Wouldn't it then make sense to have two different configuration files? One for the API and one for the CLI if they both aren't following the same schema?
I just ran into this same problem and was surprised to see the responses. Is there documentation on which API options MUST be specified via command line (if they are going to be used with babel cli)?
The crux of the issue is that the Babel CLI and the Babel API 'use' the same .babelrc file, but accept different schemas.
And the better question is why would the Babel CLI allow certain parameters to be specific in the .babelrc but not source maps? Is it because source maps is a different API in itself when used in a build system like gulp?