Bower init - diferencia entre amd, es6, globals y node

291

Estoy creando mi primer componente Bower. Después de ejecutar bower initel script, me pregunta '¿qué tipos de módulos expone este paquete?' con estas opciones:

amd
es6
globales
nodo

¿Cuál es la diferencia entre estas opciones?

— pherris
fuente

121

Si no lo sabe, es muy probable que los globales sean la respuesta correcta para usted.

De cualquier manera, debes entender:

[ACTUALIZAR]

Esta característica se introdujo recientemente en Bower y aún no está documentada (AFAIK). Básicamente, describe el moduleType, que establece para qué tecnología de módulo se debe consumir el paquete (ver arriba).

En este momento, no tiene ningún efecto aparte de establecer la moduleTypepropiedad en el bower.jsonarchivo del paquete.

Consulte https://github.com/bower/bower/pull/934 para obtener la solicitud de extracción original.

[ACTUALIZACIÓN # 2]

Algunos puntos adicionales, para responder comentarios:

en este momento AFAIK no se realiza ninguna validación en la moduleTypepropiedad, lo que significa que las personas están técnicamente autorizadas a usar el valor que deseen, incluso angularjssi se sienten inclinadas a hacerlo
El comité Bower parece no estar interesado en la inclusión de más non-interoperable/proprietary moduleTypes(piense compositor, angular, etc.), lo cual es fácilmente comprensible, pero una vez más, nada impide que las personas usen el moduleTypevalor que desean.
una excepción a lo anterior es la inclusión (algo) reciente de yui moduleType, por lo tanto, hay que hacer "excepciones", suponiendo que sean parte de un plan concertado

¿Qué haría si tuviera que crear un paquete para un administrador de paquetes no incluido en la lista y publicarlo en Bower?

Autorizaría un módulo es6 y usaría / patch es6-transpiler para generar el formato de paquete que necesito. Entonces yo / y:

solicite a los chicos de Bower que incluyan mi tecnología de paquete como una opción (en base al hecho de que es6-transpiler como objetivo)
publico mi paquete incluyendo tanto la versión del módulo es6 como la versión XXX transpilada, y utilizo es6comomoduleType

Descargo de responsabilidad: no tengo experiencia en la vida real de la creación de módulos angularjs.

— Deutz destrozado
fuente

44

¿serían las globales la respuesta correcta para crear un módulo / paquete AngularJS?

1

Actualicé mi publicación con ideas adicionales sobre la pregunta "qué hacer con los administradores de paquetes no compatibles", una vez más, este campo no es obligatorio ni se usa para nada en este momento, su valor es solo informativo. En cuanto angularjsa sí mismo, podría usar globals, sí, pero lea mi actualización. Espero que ayude.

— Mangled Deutz

Estoy usando el nodo ¿Eso significa que estoy exponiendo módulos de nodo? También estoy usando angular, que era lo que estaba instalando usando bower cuando noté que tenía un mensaje que me decía que no tenía "ningún archivo bower.json para guardar, use bower init para crear uno". (O, si se trata de una pregunta por separado, puedo escribir una pregunta. Pensé que quizás este era un comentario apropiado para poner aquí, ya que se relaciona con su respuesta. ¡Gracias!)

— PrairieProf

27

Inicial

Estoy usando bower initpor primera vez también.

Las opciones deben referirse a las diferentes formas de modularizar algún código JavaScript:

amd: usando AMD define, como requirejs.
nodo: usando Node.js require.
globales: usando el patrón del módulo JavaScript para exponer una variable global (como window.JQuery).
es6: uso de la próxima función del módulo EcmaScript6.

En mi caso, escribí un módulo dflow Node.js pero estoy usando browserify para crear un archivo dist / dflow.js que exporta un dflow global var: así que seleccioné globals .

Otras actualizaciones

El comando que utilicé para buscar el flujo de datos como un objeto global de ventana era

browserify -s dflow -e index.js -o dist/dflow.js

Lo cambié porque prefiero usar require también dentro del navegador, así que ahora estoy usando

browserify -r ./index.js:dflow -o dist/dflow.js

y entonces cambié bower.moduleType a nodo en mi archivo bower.json .

La principal motivación fue que si el nombre de mi módulo tiene un guión, por ejemplo , la vista de flujo de mi proyecto , necesito camelizar el nombre global en flowView .

Este nuevo enfoque tiene otros dos beneficios:

El nodo y la interfaz del navegador son iguales. Usando require tanto del lado del cliente como del servidor, permítanme escribir solo una vez los ejemplos de código y reutilizarlos fácilmente en ambos contextos.
Utilizo scripts npm y, por lo tanto, puedo aprovechar la ${npm_package_name}variable y escribir una vez que utilizo el script para navegador.

Este es otro tema, pero realmente vale la pena que consideres cómo es útil el último beneficio: déjame compartir el npm.scripts.browserifyatributo que uso en mi paquete.json

"browserify": "browserify -r ./index.js:${npm_package_name} -o dist/${npm_package_name}.js"

— Gianluca Casati
fuente

1

en realidad puede usar require dentro de define para ex:

define(function(require, exports, module) {   "use strict";    module.exports = {     Collection: require("./collection"),     View: require('./view')   }; });

— Doron Segal

7

Solo como referencia, esto es precisamente lo que Bower especifica con respecto a los tipos de módulos:

El tipo de módulo definido en el mainarchivo JavaScript. Puede ser una o una matriz de las siguientes cadenas:

globals: Módulo de JavaScript que se agrega al espacio de nombres global, usando window.namespaceo this.namespacesintaxis

amd: Módulo de JavaScript compatible con AMD, como RequireJS , utilizando define()sintaxis

node: Módulo de JavaScript compatible con el nodo y CommonJS utilizando module.exportssintaxis

es6: Módulo JavaScript compatible con módulos ECMAScript 6 , uso exporty importsintaxis

yui: Módulo JavaScript compatible con módulos YUI , utilizando YUI.add()sintaxis

Enlace relevante: https://github.com/bower/spec/blob/master/json.md#moduletype

— Wtower
fuente