gruntjs - nodejs - ¿Cómo administro el alias de ruta relativa en varios paquetes de grunt-browserify?

browserify transform

Question

Esto es un poco largo, pero necesitaré el ejemplo del código para ilustrar mi confusión. Después de lo cual me interesa la respuesta para lo siguiente:

1. ¿Cómo uso require(''module'') lugar de require(''../../src/module'') o require(''./module'') ?
2. ¿Cómo puedo reutilizar ./index.js en spec/specs.js sin duplicar el trabajo? (Y evita que src/app.js ejecute ya que es un módulo de entrada).

Ya he iniciado varios proyectos basados ​​en navegador y me encanta browserify y gruñir. Pero cada proyecto muere en el mismo punto de mi curva de desarrollo / aprendizaje. Una vez que agrego pruebas a la mezcla y tengo que administrar dos paquetes de browserify ( app.js y spec/specs.js ), todo el sistema se descompone. Lo explicaré:

Uso grunt-browserify y configuro mi directorio inicial:

.
├── Gruntfile.js
├── index.js (generated via grunt-browserify) [1]
├── lib
│   ├── jquery
│   │   └── jquery.js [2]
│   └── jquery-ui
│   └── jquery-ui.js [3]
├── spec
│   ├── specs.js (generated via grunt-browserify) [4]
│   └── src
│   ├── spec_helper.js (entry)
│   └── module_spec.js (entry)
└── src
   ├── app.js (entry)
   └── module.js

1. Utiliza un archivo de entrada ( src/app.js ) y realiza una caminata de código para agrupar todos los módulos requeridos .
2. Utiliza browserify-shim para alias jquery .
3. Solo tiene un alias para jquery-ui sin un shim (requerido después de que var $ = require(''jquery'') ).
4. Utiliza todos los archivos de ayuda y especificaciones en spec/src como módulos de entrada.

Voy a paso a través de mi configuración:

browserify: {
dist: {
files: {
''index.js'': [''src/app.js'']
}
}
}
// in app.js
var MyModule = require(''./module''); // <-- relative path required?!

Feliz

Ahora agregue jquery:

browserify: {
options: {
shim: {
jquery: {
path: ''lib/jquery/jquery.js'',
exports: ''$''
}
},
noParse: [''lib/**/*.js''],
alias: [
''lib/jquery-ui/jquery-ui.js:jquery-ui''
]
},
dist: {
files: {
''index.js'': [''src/app.js'']
}
}
}
// in app.js
var $ = require(''jquery'');
require(''jquery-ui'');
var MyModule = require(''./module'');

Feliz

Ahora agregue especificaciones:

options: {
shim: {
jquery: {
path: ''lib/jquery/jquery.js'',
exports: ''$''
}
},
noParse: [''lib/**/*.js''],
alias: [
''lib/jquery-ui/jquery-ui.js:jquery-ui''
]
},
dist: {
files: {
''app.js'': ''src/app.js''
}
},
spec: {
files: {
''spec/specs.js'': [''spec/src/**/*helper.js'', ''spec/src/**/*spec.js'']
}
}
// in app.js
var $ = require(''jquery'');
require(''jquery-ui'');
var MyModule = require(''./module'');
// in spec/src/module_spec.js
describe("MyModule", function() {
var MyModule = require(''../../src/module''); // <-- This looks like butt!!!
});

Triste

Para resumir: ¿Cómo puedo ...

1. Use require(''module'') lugar de require(''../../src/module'') o require(''./module'') ?
2. reutilizar ./index.js en spec/specs.js sin duplicar el trabajo? (Y evita que src/app.js ejecute ya que es un módulo de entrada).

Answer 1

Creo que la mejor manera de hacerlo es, como señala Sebastien Lorber, estableciendo la ruta en su llamada de browserify a través de una tubería.

Pero con la última versión de browserify, (a partir de este momento, que es [email protected] ), la variable de ruta almacena las únicas rutas que Browserify utilizará para su proceso. Así que establecer la variable de rutas excluirá, digamos ... sus carpetas globales para el nodo, por lo que puedo decir. Como resultado, necesitarás una tarea Gulp que se parece a esto:

gulp.task(''reactBuild'', function() {
return gulp.src(newThemeJSX)
.pipe(browserify({
debug: true,
extensions: [''.jsx'', ''.js'', ''.json''],
transform: [reactify],
paths: [''../base_folder/node_modules'', ''/usr/lib/node_modules'']
}))
.pipe(gulp.dest(newThemeBuilt))
.on(''error'', function(error) {
console.log(error);
});
});

Answer 2

Estas respuestas dependen de cómo se configura el resto de su proyecto, pero tal vez sea un buen punto de partida. Además, deberá usar la versión beta v2 actual de grunt-browserify para que esto realmente funcione ( npm install grunt-browserify@2 ).

1.

Puede usar aliasMapping para crear algunos alias dinámicos para sus módulos. Solo por claridad, movamos todos sus módulos a src/modules/ . Entonces, la configuración de aliasMapping podría ser algo como esto:

options: {
aliasMappings: {
cwd: ''src'',
src: [''modules/**/*.js'']
}
}

Supongamos que tiene un módulo en src/modules/magic/stuff.js , entonces puede requerirlo así, independientemente de dónde se encuentre el archivo .js que está haciendo el requisito:

var magicStuff = require(''modules/magic/stuff.js'');

2.

No estoy seguro de este. La estructura de su proyecto muestra un spec/index.js , pero usted menciona spec/specs.js . ¿Se supone que son el mismo archivo?

De todos modos, ¿de qué trabajo duplicado estás hablando? Porque ./index.js tiene un archivo de entrada diferente al de spec/index.js . Si está buscando una manera de incluir ./index.js en las specs/ , tal vez pueda copiarlo antes de ejecutar las pruebas en lugar de ./index.js desde cero.

Answer 3

Todas las respuestas aquí sobre los alias y opts.paths / $NODE_PATH no son excelentes porque ese enfoque es una parte obsoleta del sistema de módulos en el nodo y browserify, por lo que podría dejar de funcionar en cualquier momento.

Debería aprender cómo funciona el algoritmo node_modules para poder organizar su código de manera efectiva de manera que funcione bien con los directorios de node_modules anidados.

Hay una sección en el manual de browserify que cubre evitar los problemas de ruta relativa de .../../../../../../ . Se puede resumir como:

• Ponga su código modular interno en node_modules/ o node_modules/app para que pueda require(''yourmodule'') o require(''app/yourmodule'') dependiendo de cuál prefiera.
• Puede usar un enlace simbólico si está desarrollando para plataformas que no son Windows y eso es lo que prefiere.

No utilice opts.path / $NODE_PATH . Hace que tu proyecto:

• Depende implícitamente de una configuración o entorno no obvios
• Más difícil hacer funcionar tanto en el nodo como en el navegador.
• vulnerable a los cambios en el sistema de módulos, ya que las rutas de la matriz están en desuso en el nodo y browserify

Answer 4

Respuesta simple:

Lo más sencillo es utilizar la opción de paths de browserify. Lo uso desde hace algunos meses con gran éxito. Incluso he hecho un kit de inicio que utiliza esta función: https://github.com/stample/gulp-browserify-react-phonegap-starter

var b = browserify(''./app'', {paths: [''./node_modules'',''./src/js'']});

rutas - la matriz require.paths que se utilizará si no se encuentra nada en la caminata recursiva normal de node_modules

Si tiene un archivo en src/js/modulePath/myModule.js esto no le permitirá escribir require("myModule") todas partes, sino que require("modulePath/myModule") , de cualquiera de sus otros archivos fuente.

¿Opción obsoleta?

¡No lo parece!

El algoritmo de resolución del módulo Browserify refleja el algoritmo de resolución en NodeJS . La opción de paths de Browserify es, por lo tanto, la réplica del comportamiento de la variable NODE_PATH env para NodeJS. El autor de Browserify (subestaca) afirma en este tema SO que la opción NODE_PATH está en desuso en NodeJS y, por lo tanto, también está en desuso en Browserify y podría eliminarse en las próximas versiones.

No estoy de acuerdo con esta afirmación.

Consulte la documentación de NODE_PATH . No se menciona que la opción esté en desuso. Sin embargo, todavía hay una mención interesante que lo hace en la dirección de la subestación:

Se recomienda encarecidamente que coloque sus dependencias localmente en las carpetas node_modules. Se cargarán más rápido y de manera más confiable.

Y esta pregunta ha sido publicada en 2012 en la lista de correo.

Oliver Leics: is NODE_PATH deprecated?
Ben Noordhuis (ex core NodeJS contributor): No. Why do you ask?

Y si algo no se elimina en el algoritmo de resolución NodeJS, no creo que se eliminará pronto de Browserify :)

Conclusión

Puede usar la opción de paths o poner su código en node_modules como la documentación oficial y el autor de Browserify recomienda .

Personalmente, no me gusta la idea de poner mi propio código en node_modules ya que simplemente mantengo toda esta carpeta fuera de mi control de código fuente. Utilizo la opción de paths desde hace algunos meses y no tuve ningún problema, y ​​mi velocidad de construcción es bastante buena.

La solución de subestación de poner un enlace simbólico dentro de los node_modules podría ser conveniente, pero desafortunadamente tenemos desarrolladores que trabajan con Windows aquí ...

Sin embargo, creo que hay un caso en el que no desea utilizar la opción de paths : cuando está desarrollando una biblioteca publicada en un repositorio NPM que serán requeridas por otras aplicaciones. Realmente no quieres que estos clientes de la biblioteca tengan que configurar configuraciones especiales de compilación simplemente porque quisiste evitar el infierno de ruta relativa en tu biblioteca.

Otra opción posible es usar remapify