Je crée mon premier composant Bower. Après avoir exécuté bower init
le script, il me demande "quels types de modules ce package expose-t-il?" avec ces options:
- amd
- es6
- globals
- nœud
quelle est la différence entre ces options?
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 utiliserglobals
, oui, mais lisez ma mise à jour. J'espère que cela pourra aider.Initiale
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 .
Autres mises à jour
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"
la source
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:
Lien pertinent: https://github.com/bower/spec/blob/master/json.md#moduletype
la source