Is there any way to emulate factor-bundle and create a single common bundle?

[wc-matteo]

A single common bundle even if the module is not required by all original bundles (i.e. have a custom threshold).

I've tried various things with little success... if there's no simple way, do you have any idea how much work would take to have factor-bundle play nice with this plugin? I also tried that, but wasn't particularly successful either...

[springuper]

I'm sure common-bundle has the ability to satisfy your requirement, please @zoubin give more detail.

[zoubin]

@wc-matteo

A single common bundle even if the module is not required by all original bundles (i.e. have a custom threshold).

Do you mean to include some specific modules into the common bundle?
If so, I think we could add a options.common.threshold like factor-bundle does.

• Number. If required by more than n original bundles, then should go to the common bundle
• Function. Signature: threshold(moduleFile, numberOfRequiringBundles).

[wc-matteo]

Yep, that's exactly it! ;)

Thank you very much for the quick (and positive) response. I really like what you're doing with reduce{js,css}!

The best I got was to do:

common: [
  {
    output: 'lib/common.js',
    filter: ['lib/a.js', 'lib/b.js']
  },
  {
    output: 'lib/common.js',
    filter: ['lib/a.js', 'lib/c.js']
  },
  {
    output: 'lib/common.js',
    filter: ['lib/b.js', 'lib/c.js']
  }
]

I.e. try all combinations of two elements, but alas the output (as you hinted in the README) is not modified a second time.

---

@zoubin If I may ask, do you have any opinions on Webpack? I heard that if one needs to split bundles in complex ways, it gives you more control than other tools.

Have you seen this? Pity that the author seems to have abandoned it and now it doesn't work on the latest versions of Browserify (it calls the method dep, which I assume must have been exposed in the older versions).

[zoubin]

Actually, the common option is used to set the dependency relationship between bundles.
If bundle a.js is declared to depend on b.js, modules in b.js should not be included in a.js, because 'depend' means that b.js should be loaded before a.js, no need to load them again from a.js.
However, if b.js does not exist yet, it should be created and contain the common modules shared by its dependents in the current configure.

common: [
  // Declare that both a.js and b.js should depend on common.js
  // As common.js does not exist, it is created to contain modules shared
 // by both a.js and b.js
  {
    output: 'lib/common.js',
    filter: ['lib/a.js', 'lib/b.js']
  },

  // Declare that a.js and c.js should depend on common.js
  // As common.js already exists, no extra bundle need to be created
  // But modules in c.js are removed if they are also in common.js
  // Since a.js has already been declared to depend on common.js in the previous
  // configure, nothing will happen to it here
  // In a word, this configure will NOT modify the contents of common.js
  // It only removes some modules from c.js
  {
    output: 'lib/common.js',
    filter: ['lib/a.js', 'lib/c.js']
  },

  // declare that b.js and c.js should depend on common.js
  // they already does, so nothing happens
  {
    output: 'lib/common.js',
    filter: ['lib/b.js', 'lib/c.js']
  }
]

[zoubin]

Webpack is really powerful in code splitting. I have been considering mimic its code-splitting in this repo 😄

The main reason why we prefer browserify to webpack is that webpack is too heavy and less flexible than browserify.

We need a tool to bundle css modules, but webpack and browserify seem to handle them in a 'css-in-js' way, which means you have to require styles in js. A little odd, because the js really has nothing to do with the styles (unless you are using some tools like css-modules, that is another story).
So we decide to build depsify. It is designed to be 'a browserify for css'. With the same pipeline structure, browserify and depsify could share some plugins, like common-bundle, watchify, etc.

As you can see, common-bundle is a tool for packing modules, css or js, as long as the module representation has the same structure. In this way we can pack styles in the same way we pack js, like common-shared bundles. It is hard to implement the same packing strategy for both css and js in webpack.

Besides, we are also working on reduce-web-component, a tool for bundling components. It is built on reduce-js and reduce-css by synchronizing their pipelines. It seems the smaller and more flexible framework of browserify brings about rich possibilities.

I have not look into multi-bundle yet. It seems to do some similar things. Interesting. Thank you for telling me that information.

[wc-matteo]

Actually, the common option is used to set the dependency relationship between bundles.

Yes, I get that.
At least... I think I do! :P

What my intention with that configuration was:

All dependencies shared by a and b should go to common
All dependencies shared by a and c should also go to common
All dependencies shared by b and c should also go to common

If I could just "append" to common (avoiding duplicates), I would not need a custom threshold: I could just input all combinations (all combinations of 2 with this system should be equal to a threshold of 1, if I am not mistaken).

But obviously that's not how output is implemented; and probably for good reasons! :) Anyway, configurable thresholds is far superior (for my use case) to computing all possible configurations like above.

---

What you say about CSS bundles is exactly what I'm looking for. The tools I've seen usually, as you say, are written with js modules in mind and are only adapted (often badly) to work with other languages (CSS in this case); for instance, I found that these tools let you embed/inject CSS really easily but have poor support for creating file bundles.

I haven't looked at web-component yet but, now that you mention it, could be that it's the logical choice for someone like me interested in reduce-js & reduce-css.

In all the examples (web-component, reduce-js), you use the page as the unit to base bundles on (i.e. 1 bundle per page); is there any reason you would think that different units (e.g. 1 bundle for core stuff, each major component in its own bundle, etc.) may cause trouble?

When (and if) you have time: what are your opinions on css modules and dynamic loaders (of dependencies)?

Thank you again for your helpfulness! :)

[zoubin]

@wc-matteo

Yes, I get that.
At least... I think I do! :P

I find it a little confusing, too.
So some changes are introduced in 0.5.0.
I think this release is probably what you need.

If I could just "append" to common (avoiding duplicates

dynamic loaders can optimize the initial load if applied properly, but all developers could introduce some changes to your loading scheme, and may make it less efficient day by day.

As for css modules, I have not used it in actual projects yet.
It provides a way to avoid name collision, but it is tricker to overrides rules from other modules (perhaps there is some easy ways I don't know to do this).

So, I believe there are always balances 😄