Réponses:
Si vous ne le savez pas, il est fort probable que global soit la bonne réponse pour vous.
Quoi qu'il en soit, vous devez comprendre:
Cette fonctionnalité a été introduite très récemment dans Bower et n'est pas encore documentée (AFAIK). Il décrit essentiellement le moduleType
, qui indique pour quelle technologie de module le package est destiné à être consommé (voir ci-dessus).
À l'heure actuelle, cela n'a aucun effet en dehors de la définition de la moduleType
propriété dans le bower.json
fichier du package.
Voir https://github.com/bower/bower/pull/934 pour la demande de traction d'origine.
Quelques points supplémentaires, pour répondre aux commentaires:
moduleType
propriété - ce qui signifie que les gens sont techniquement autorisés à utiliser la valeur qu'ils souhaitent pour cela, y compris angularjs
s'ils se sentent enclins à le fairenon-interoperable/proprietary moduleTypes
(pensez compositeur, angulaire, etc.) - ce qui est facilement compréhensible, mais encore une fois, rien n'empêche vraiment les gens d'utiliser la moduleType
valeur qu'ils souhaitentyui moduleType
, donc, il y a des "exceptions" à faire, en supposant qu'elles font partie d'un plan concertéQue ferais-je si je devais créer un package pour un gestionnaire de packages non répertorié et le publier sur bower?
Je voudrais créer un module es6 et utiliser / patch es6-transpiler pour sortir le format de package dont j'ai besoin. Alors je voudrais soit / et:
es6
commemoduleType
Avertissement: je n'ai pas d'expérience réelle dans la création de modules angularjs.
angularjs
à lui-même, je pourrais utiliser globals
, oui, mais lisez ma mise à jour. J'espère que cela pourra aider.
J'utilise aussi bower init
pour la première fois.
Les options doivent faire référence aux différentes façons de modulariser du code JavaScript:
define
, comme requirejs.require
.Dans mon cas, j'ai écrit un dflow de module Node.js mais j'utilise browserify pour créer un fichier dist / dflow.js qui exporte une var globale de dflow : j'ai donc sélectionné des globaux .
La commande que j'ai utilisée pour explorer dflow en tant qu'objet global de fenêtre était
browserify -s dflow -e index.js -o dist/dflow.js
Je l'ai changé car je préfère utiliser require également dans le navigateur, donc maintenant j'utilise
browserify -r ./index.js:dflow -o dist/dflow.js
et j'ai donc changé le bower.moduleType en nœud dans mon fichier bower.json .
La principale motivation était que si le nom de mon module avait un tiret, par exemple la vue de flux de mon projet , je devais caméliser le nom global dans flowView .
Cette nouvelle approche présente deux autres avantages:
${npm_package_name}
variable et écrire une fois le script que j'utilise pour naviguer.Ceci est un autre sujet, mais il vaut vraiment la peine de considérer l'utilité de ce dernier avantage: permettez-moi de partager l' npm.scripts.browserify
attribut que j'utilise dans mon package.json
"browserify": "browserify -r ./index.js:${npm_package_name} -o dist/${npm_package_name}.js"
define(function(require, exports, module) { "use strict"; module.exports = { Collection: require("./collection"), View: require('./view') }; });
Juste pour référence, c'est précisément ce que bower spécifie concernant les types de modules:
Type de module défini dans le
main
fichier JavaScript. Peut être une ou un tableau des chaînes suivantes:
globals
: Module JavaScript qui ajoute à l'espace de noms global, en utilisantwindow.namespace
ou lathis.namespace
syntaxeamd
: Module JavaScript compatible avec AMD, comme RequireJS , utilisant ladefine()
syntaxenode
: Module JavaScript compatible avec node et CommonJS utilisant lamodule.exports
syntaxees6
: Module JavaScript compatible avec les modules ECMAScript 6 , utilisationexport
etimport
syntaxeyui
: Module JavaScript compatible avec les modules YUI , utilisant laYUI.add()
syntaxe
Lien pertinent: https://github.com/bower/spec/blob/master/json.md#moduletype