Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shortcomings of bundles features #1034

Closed
ghost opened this issue Feb 18, 2014 · 6 comments
Closed

Shortcomings of bundles features #1034

ghost opened this issue Feb 18, 2014 · 6 comments

Comments

@ghost
Copy link

ghost commented Feb 18, 2014

The bundles feature which was introduced in version 2.1.10 sounds very useful, but unfortunately it is a bit misleading.

I would expect this feature to work in the following way:
Assume a bundle is defined as
bundles: {
"primary": ["main", "util"]
}

When making a require for "primary", modules main and util should be passed in the same order as they are declared in the bundle. Example:
define(["primary"], function(main, util){})

Bundles should also work with deps. Example:
deps: ["primary"] should load main and util.

Bundles should work with r.js optimizer. Example:
include: ["primary"] should include modules main and util into the optimized file.

With these adjustments, the bundles feature would be really useful for removing code (modules list) duplication in large multi-page projects. You could define the bundles once and then reuse this configuration for multiple purposes.

@ghost
Copy link
Author

ghost commented Feb 18, 2014

By the way, I am not the only person who wished it worked this way. See https://groups.google.com/forum/#!topic/requirejs/MqJouSkI1U0

@jrburke
Copy link
Member

jrburke commented Feb 19, 2014

I apologize for the confusing docs. I just pushed a change to the API doc to try to clarify: it is just a way to locate where to find a module for loading, it does not automatically bind module exports to some other module export. There are no plans to offer such a feature.

There is the sugar syntax that fits some needs, but that is the extent of the capabilities beyond the explicit dependency array.

@ghost
Copy link
Author

ghost commented Feb 19, 2014

Thanks for clarifying the docs. But what do you think about suggestions to enhance the bundles functionality as described in this issue? Since this functionality is not supported yet, it should not be a breaking change.

@jrburke
Copy link
Member

jrburke commented Feb 19, 2014

That feature request goes against the explicit dependency goals for modules: a module should declare its dependencies and its exports itself. The feature request would be misleading if someone asks for 'primary' but did not set up the configuration call.

Plus, this sort of feature is not planned for ES6 modules, so I do not want to add anything that makes it harder to convert up to them later.

It is possible to get a similar effect to the feature request by just doing this after a config call, but before anything loads:

define('primary', function(require) {
  return {
    util: require('util'),
    main: require('main')
  };
});

require(['primary'], function(primary) {
  // primary.util, primary.main
  // with destructuring assignment:
  var { util, main } = primary;
});

So a bit more wordy, but stays with explicit dependency goals.

@isochronous
Copy link

Wow, until I saw that last line I didn't even know you could do that in Javascript. Learn something new every day!

@neonstalwart
Copy link
Contributor

@isochronous be careful... for most practical purposes you can't do that (yet).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants