Not able to use standalone & require flags at the same time

[piranna]

As notified at browserify/browserify#939, I'm not able to generate a bundle that at the same time can be used standalone and also export its content so it can be required by other bundles, that it's useful for frameworks that can use build-in and external plugins at the same time. Reviewing the code, there's a conditional that explicit forbit this use case, so I would like to know if it's on purposse and why, or if this could be fixed for this use case (I think it's possible, but needs to investigate a little bit more the code...).

[jmm]

I'd like to know the reasoning for this as well. Is there some reason a standalone bundle can't also export a require()?

[ForbesLindesay]

At the moment, nobody's done the work to make those two things function together, so just removing the conditional would not be enough to make it work.

How would the resulting code determine whether to set require or expose itself as a global via standalone?

[piranna]

How would the resulting code determine whether to set require or expose itself as a global via standalone?

Simply by doing both things, so it's available as a global and by require().

[jmm]

@ForbesLindesay If I do the work can I expect it to be merged?

[ForbesLindesay]

Doing both things seems like a really dirty hack. You end up with a bonus global either way.

[jmm]

That sounds like an indictment of standalone mode in general. How is it a dirty hack to also export a require() function (that allows you to utilize the bundle in the same fashion as non-standalone bundles that expose files) if you're already doing standalone?

You end up with a bonus global either way.

You mean you end up with the global created by standalone mode either way?

[piranna]

In the plugins scheme we are using at my work, it's a valid use case, since our librare can be used standalone, but at the same time the third party plugins would want to require() its resources. It's a worst hack to explicitly expose it globally as we need to o at this moment...

[ForbesLindesay]

@jmm You either end up with require when you didn't want it or ModuleName when you didn't want that. Either way you lose because you wanted something else.

@piranna that does sound like a valid use case.

[piranna]

@piranna that does sound like a valid use case.

I'm happy you think so :-) The hack we are currently using at my job is to have a browser entry at package.json pointing to a file that only has the next lines:

/**
 * Loader for the kurento-client package on the browser
 */

if (typeof kurentoClient == 'undefined')
  window.kurentoClient = require('kurento-client');

Later, we generate a non-standalone browser library exporting kurento-client so it can be require()d, so this way we can be able to export it both as a global namespace to use it as a standalone library and to be required by the third-party libraries at the same time. Being a so simple hack I don't think there's a reason to be set both options as mutually exclusive in the code...

[jmm]

@ForbesLindesay

@jmm You either end up with require when you didn't want it or ModuleName when you didn't want that. Either way you lose because you wanted something else.

How do you figure? Currently when doing standalone you can't get the require() from browserify if you do want it.

Standalone is currently an explicit opt-in mechanism.

Exposing files from bundles with a global require() is currently an opt-in feature. It's what you do if you want require() but don't want ModuleName.

When doing standalone, then also doing require() can be opt-in instead of implicit if that's what makes sense. The only concrete reason I've thought of so far for making it opt-in is if someone wants to do something like this and not have the exposed module from bundle A masked by bundle B:

/* Bundle A */
browserify()
  .require('whatever', {expose: 'ModuleName'})

/* Bundle B */
browserify({
  standalone: 'ModuleName'
})

<script src="bundle-a.js"></script>
<script src="bundle-b.js"></script>

[jmm]

PR #51 submitted.