specifying browserify options (plugins, extensions)

[goto-bus-stop]

ref #285, #262

currently you can only specify browserify transforms using the browserify.transform key in package.json. altlangs like typescript and coffeescript use custom (non-.js) extensions though which cannot be configured in package.json.

@yoshuawuyts & i chatted about this recently--adding some custom logic to bankai that reads additional configuration from the application's package.json only (not from package.json in dependencies) could be a nice option:

// for typescript
{
  "browserify": {
    "plugin": [ "tsify" ]
  }
}
// for coffeescript
{
  "browserify": {
    "extensions": [ ".coffee" ],
    "transform": [ "coffeeify" ]
  }
}

this still leaves out plugins that need things like functions in their options, but you could work around that by wrapping it in a small plugin like so:

// package.json
{
  "browserify": {
    "plugin": [ "./browserifyConfig" ]
  }
}
// browserifyConfig.js
module.exports = function (b) {
  b.plugin('some-plugin', { option: function () {} })
}

anyone have more thoughts on this?

[s3ththompson]

Just ran into this issue as well! Custom logic seems a bit hacky--is there any chance @substack would accept an upstream PR to add something like this to browserify core?

Alternately, perhaps we could carve out a typescript-specific solution? I feel like now that Choo has typescript support it would be great if Bankai supported it out-of-the-box too!

[s3ththompson]

From irc:

<s3ththompson>: goto-bus-stop: just ran into bankai #359 (supporting typescript plugin in browserify) and saw you opened an issue! is there any chance upstream browserify would accept a PR to start reading a plugin config key in package.json?
<substack>: s3ththompson: package.json is for transforms only, because you might have a dependency with a package.json transform configured
plugins aren't so clean as that

[goto-bus-stop]

Yep, thanks for adding that. I also agree with you that custom logic might be confusing. I suggested a `bankai` package.json key but yosh mentioned that the duplication might be annoying (having both `bankai.browserify.plugin` and `browserify.transform`). I think that may be a minor problem compared to the alternatives tho.

…

On 31 December 2017 21:54:10 CET, Seth Thompson ***@***.***> wrote: From irc: > \<s3ththompson\>: goto-bus-stop: just ran into bankai #359 (supporting typescript plugin in browserify) and saw you opened an issue! is there any chance upstream browserify would accept a PR to start reading a plugin config key in package.json? > \<substack\>: s3ththompson: package.json is for transforms only, because you might have a dependency with a package.json transform configured > plugins aren't so clean as that -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #359 (comment)

-- Sent from mobile. Please excuse my brevity.

[yoshuawuyts]

Alternately, perhaps we could carve out a typescript-specific solution? I feel like now that Choo has typescript support it would be great if Bankai supported it out-of-the-box too!

I wonder what this would look like; perhaps a separate issue might be cool for this? I'm open to the idea, especially because so far it seems to be the only direct use case we have for a plugin!

[goto-bus-stop]

adding support for a module-scoped browserify.extensions key inside browserify upstream, like described in browserify/browserify#809, would address the coffeescript case. if we do that + support typescript out of the box we would've addressed probably 99% of use cases for this issue

[yoshuawuyts]

@goto-bus-stop yeah, that seems reasonable!