Allow the user to pass in additional babel specific options

[silkentrance]

Considering the current set of babel specific options and the available options, it seems that it would be best to support additional options

Nice to have

    --no-non-standard                    enable/disable support for JSX and Flow (on by default)
    --experimental                       allow use of experimental transformers
    --optional [transformerList]         list of optional transformers to enable
    -b, --blacklist [transformerList]    blacklist of transformers to NOT use
    -l, --whitelist [transformerList]    whitelist of transformers to ONLY use
    -L, --loose [transformerList]        list of transformers to enable loose mode ON
    -P, --jsx-pragma [string]            custom pragma to use with JSX (same functionality as @jsx comments)
    --plugins [list]                     
    -r, --external-helpers               uses a reference to `babelHelpers` instead of placing helpers at the top of your code.

Not so sure about these, though

    -m, --modules [string]               module formatter type to use [common]
    --module-root [string]               optional prefix for the AMD module formatter that will be prepend to the filename on module definitions
    --module-id [string]                 specify a custom name for module ids
    -M, --module-ids                     insert an explicit id for modules

Alternatively, these could be specified in a config file.

[jeffrifwald]

Experimental is now the stage command, it is supported currently with --babel-stage.

For the rest, I encourage you to open a pull request with those flags implemented. I might be able to add some of them soon, but I'm not sure.

[silkentrance]

Okay, I have just looked at grunt-istanbul, which allows one to pass in custom instrumenters. Would be nice to have this integrate into that as well. I will have a look at this and provide you with a PR.

[jeffrifwald]

You can probably already integrate into grunt-istanbul by passing in the correct options and importing the instrumenter from babel-istanbul. I'm not sure on that though, as I don't know how they parse their options.

[tikotzky]

instead of duplicating all babels options as flags in babel-istanbul, why dont you just suggest placing a .babelrc in the root of the project. This way you can get rid of all babel options and if you need to pass options to babel you just do it in the .babelrc file.

see: https://babeljs.io/docs/usage/babelrc/

[jeffrifwald]

@tikotzky I'd still want to duplicate the flags on the command line if you used a babelrc file. I built this tool so I could do what I wanted from the command line with or without config file magic, so other similar tools only implement a subset of the command line args I wanted for istanbul.

Also, your babelrc setup might be slightly different for test running. For example, you might want to require the babel runtime for test running, but handle that in a different way for builds. Long story short, you'd need to provide the corresponding overrides anyway.

[jeffrifwald]

Also @tikotzky, you can pass all of the supported options through the istanbul.yml file.

[tikotzky]

Hmm... .babelrc allows you to have multiple envs in you config file which is how I do testing now. (see https://babeljs.io/docs/usage/babelrc/#env-option)

The reason I personally like using a babelrc is because this way I get the same set of babel options no matter which tool i'm using. So for example if I decide to enable a specific transform I just need to enable it the .babelrc instead of all the places which call into babel.

[jeffrifwald]

I wouldn't be opposed to reading a babelrc file, we'll just have to support turning it off if needed. We'll also need to support all the command line args anyway. I encourage you to open a pull request!

[tikotzky]

Well actually what I was saying is that you already support a .babelrc file :smile:

since when you invoke babel it will always look for a .babelrc it actually works right now with babel-istanbul, I guess it just needs to be documented.

[jeffrifwald]

Ah gotcha, I didn't realize the compile command did that automatically. Thanks for pointing that out!

[jeffrifwald]

With that being said @silkentrance, you can enable unsupported options with a .babelrc file. I still encourage you to add more command line arguments for things you might need often. Thanks!