Request: support for babel options as an object

[MoOx]

I think webpack provide an API to accept any kind of option (query string or object) via the webpack instance .option[key] but I am not sure.
That being said, that could be great to define options like this

{
  //...
  babel: {
    experimental: true,
    playground: true,
    optional: [
      "runtime",
      "spec.protoToAssign",
    ],
    loose: "all",
  },
}

(And because query strings are so ugly)

Example of loader I made that use this simple way to read option:

https://github.com/MoOx/eslint-loader/blob/defe509dbb98e31d781dae35fa544c350730c411/index.js#L73
https://github.com/cssnext/cssnext-loader/blob/c7b79f5281a5e63adca933fc4ec434f965e686e3/index.js#L22

[Couto]

I'm not really sure if I understood your point correctly, but webpack accepts json in the querystring: https://github.com/webpack/loader-utils

so I guess you could pass the object by 'json.stringifying' it into the query.

[MoOx]

i've done that. But it will much cleaner to support global webpack object for option too. I guess most people use babel-loader once.
Stringify on the front to unstringify on the back is not optimized.

[Couto]

While I can understand the point of legibility and convenience (and I do agree that query strings are far from perfect) I get the feeling that this is something that should be supported by webpack itself, instead of having plugins "extending" the functionality with no major gains.

I honestly think that this issue should be issued to webpack instead of the loaders, since that way every loader would benefit from the change, and users wouldn't have to deal with different ways of passing options.

Anyway I wouldn't mind to listen the opinion of @sebmck since he also maintains the loader.

[sebmck]

@Couto I don't really have an opinion since I don't personally use webpack so I have no idea what's most convenient for people so feel free to take the lead on this one. 😄

[Couto]

I tried to search around the issues in webpack and I found #482 I think this solves the problem.

I'm closing this. Since I prefer to be consistent and predictable with other loaders, if the way of passing options changes, or something else becomes the norm, I don't mind at all to adapt.

[Couto]

Just to make it clear :)

I think you should open an issue in webpack's issue tracker, suggesting your way of passing options.
You'll have my support on that. The current way of passing options is awkward to say the least. I just don't think that this should be fixed at the loader level.

[MoOx]

The way I suggest option is already supported by webpack, it's just another webpack API to use in the loader itself. I can only advice you to double check the links I mentioned earlier in the issue and check API of those loaders well, you should get it.

Example

// webpack.config.js
module.exports = {
  //...
  module: {
    loaders: [
    {
      test:   /\.js$/,
      loader: "babel-loader!a&b"
    }
    ],
  },
  babel: {
    a: false,
    b: false,
    c: true,
  },
}

// babel-loader
module.exports = function(input) {
  // you will just need to update this lines in babel-loader
  // this merge global option + loader specific option
  // making you able to have global babel option + specific loader option
  // (in case you use babel-loader differently on some files according to your regex test)
  var options = Object.assign({}, this.options.babel, loaderUtils.parseQuery(this.query))
  // options are {a: true, b: true, c: true}
}

[Couto]

I checked the links, I understood the implementation.

Can you give me a link to some issue or docs showing that webpack "officially" supports that way of reading options?

I just need something from webpack stating that I can do this, instead of relying on undocumented options that later can disappear.

[MoOx]

I think this is it http://webpack.github.io/docs/loaders.html#options

[Couto]

Works for me then

Are you up for a PR? Otherwise I’ll only be able to do it during the weekend.

On 26 Mar 2015, at 18:06, Maxime Thirouin notifications@github.com wrote:

I think this is it http://webpack.github.io/docs/loaders.html#options

—
Reply to this email directly or view it on GitHub.

[MoOx]

I will try to do that tomorrow morning.

[MoOx]

With ddos attacks I can't fork this morning :(
I will try later if you didn't do it before me :)
FYI, I implemented the same thing we discuss in eslint-loader (but can't show you right now since push on github isn't working for now :D)

[Couto]

Worry not :)

I'll be merging the branch with develop later.

[vjpr]

+1

[Couto]

@vjpr that's already implemented in the develop branch I'm just trying to find some free time to make a release.

[sebmck]

You can already provide webpack loader query options via an object:

module.exports = {
  module: {
    loaders: [
      {
        test: /\.js$/
        exclude: /node_modules/,
        loader: 'babel-loader',
        query: {
          // your babel options here
        }
      }
    ]
  }
};

Adding yet another way to specify options is probably going to be awkward.

[Couto]

Uh! that is new, and nice :)
I think the main advantage was to have a global option object, but this makes everything easier :)

[MoOx]

Hum, so I guess we can close this issue ?

[dashed]

Probably a compromise would be to just update README to show this in addition to the shorthand (e.g. loader: 'babel-loader?optional=runtime').

[deini]

Sorry to bring back this issue to life but could we consider this again? I think I have a legitimate use case.

I'm trying to use Babel's getModuleId option which expects a function. However we can't pass functions through query.

Please correct me if I'm wrong (and I hope I am)

This is also related to #118

[MoOx]

You can. Query accept a real object #46 (comment)

[deini]

Which AFAIK gets stringified, and loses the function.

[deini]

Letting this here just in case somebody else tumbles to this.

Just went trough the code and figured I can do this by just passing babel: {} to the webpack config.

https://github.com/babel/babel-loader/blob/master/index.js#L36 I don't think its documented.