If you don't know, it's quite likely globals is the right answer for you.
Either way, you need to understand:
[UPDATE]
This feature was introduced very recently in bower and is not documented at all yet (AFAIK). It essentially describes the moduleType
, which states for what module technology the package is meant to be consumed (see above).
Right now, It doesn't have any effect apart from setting the moduleType
property in the bower.json
file of the package.
See https://github.com/bower/bower/pull/934 for the original pull-request.
[UPDATE #2]
A few additional points, to answer comments:
- right now AFAIK there is no validation done on the
moduleType
property - which means that people are technically allowed to use whatever value they want for it, includingangularjs
if they feel inclined to do so - the bower committee seems to not be keen toward the inclusion of additional
non-interoperable/proprietary moduleTypes
(think composer, angular, etc) - which is easily understandable, but yet again, nothing really prevents people from using themoduleType
value they want - an exception to the previous is the (somewhat) recent inclusion of the
yui moduleType
, so, there are "exceptions" to be made, assuming they are part of a concerted plan
What I would do if I were to author a package for a not-listed package manager and publish it on bower?
I would author an es6 module, and use / patch es6-transpiler to output the package format I need. Then I would either/and:
- petition the bower guys to include my package technology as a choice (based on the fact it's supported by es6-transpiler as a target)
- publish my package including both the es6 module version of it and the transpiled XXX version of it, and use
es6
as amoduleType
Disclaimer: I don't have real-life experience authoring angularjs modules.