use browserify options from package.json if available about bankai HOT 9 CLOSED

Or some other way to tell bankai to inherit the config of browserify, like ava does for babel config:

"ava" {
  "babel": "inherit"
}

from bankai.

💯 this would be great

from bankai.

Nice idea! I'm not sure if it is optimal to seize the browserify key, though. Can we achieve the same convenience if we read config from the usual places under a bankai key? We could do this easily with e.g. cosmiconfig

from bankai.

For reference / parity, budo works with the config in the browserify field. If we go with the proposed bankai key, it would still be useful to have it fallback to the browserify key when a bankai specific one is not present.

from bankai.

I think the browserify key makes most sense because:

1. It works the same as with browserify, meaning there's nothing new to learn
2. It provides parity with wzrd, budo and beefy, further reducing friction
3. It's easier to upgrade to bankai from any other tool

The less special we make bankai the better I reckon

from bankai.

Okay, then as a general rule of thumb browserify => bankai.js holds true.

I assume we want to allow file based config of all bankai features at some point, so that would mean bankai and browserify keys can coexist in certain scenarios.

The precedence chain should be bankai.js > browserify, bankai[format] > format-tool in general, I guess.

from bankai.

yeah, sounds alright. Though I wonder if we'll ever arrive at a point where we need bankai specific config; if we ever reach that point I feel it would be good to take a step back and reflect on what we're doing and if couldn't simplify it hah

from bankai.

Doesn't this already happen? I set up the basic example to demonstrate this I thought? https://github.com/yoshuawuyts/bankai/tree/master/example/basic

from bankai.

I think this should work; if not passing { basedir: __dirname } or something to browserify (js:) in the constructor should probs resolve it - closing for now

from bankai.