5

I'm creating a meteor package for a JS library that contains a number of optional plugins in the main repository. I would like to provide the option for the user to select which library extensions to use, without always including them unnecessarily.

Is this possible with the current build system? If so, where do I begin?

bigmadwolf
  • 3,419
  • 3
  • 30
  • 44
  • 1
    Dumb & dirty solution: Create one package per option. I'll be glad if someone finds a better one! – Kyll Nov 18 '15 at 10:35
  • Yeah really not keen on that approach, and becomes a nightmare to maintain, I hopeful that theres a better way. – bigmadwolf Nov 18 '15 at 10:41
  • There might be a way to do this in some instances using asynchronous loading of scripts, but that becomes a whole thing, and would be much better to handle in the build. – bigmadwolf Nov 18 '15 at 10:42
  • Maybe if you had access to Meteor settings, you could only `api.[use/imply]` a selection of packages? – Kyll Nov 18 '15 at 10:43
  • 1
    This type of requirement (which I share) has been discussed in the past([1](https://github.com/MeteorCommunity/discussions/issues/11), [2](https://github.com/meteor/meteor/issues/1292), probably more), so far without results that I am aware of. Perhaps explicit ES6 module imports will help, when Meteor supports those out of the box. – MasterAM Nov 18 '15 at 12:25

1 Answers1

1

This is not currently supported. In a sense, each package is the "option" you enable through the package system itself. Your current best bet is to just publish packages for each piece and maybe add packages for common build combinations.

Twitter Bootstrap currently does something similar like so:

twbs:bootstrap          // normal bootstrap
twbs:bootstrap-noglyph  // bootstrap sans glpyhs

Also relevant, some of the (many) pre-packaged stylus packages out there:

stolinski:stylus-multi
cryptoquick:stylus-multi
mquandalle:stylus

I look forward to this answer going stale.

Jesse
  • 2,043
  • 9
  • 28
  • 45
  • 1
    Note that, if there is more than a couple options and they are composable it becomes completely unmaintainable. 5 composable options is 120 packages to maintain. – Kyll Nov 18 '15 at 15:17
  • @Kyll agreed. The other option is to include all the things into one bloated package. – Jesse Nov 18 '15 at 15:27
  • Its quite frustrating actually, maybe modules will solve it, but its pretty critical for a lot of libraries. async could be used, when initializing a package, but its going to get messy, and then we're hacking with assets api.... going to look a little longer, but this seems like the only viable answer, for now. – bigmadwolf Nov 18 '15 at 15:52