Node-vibrant: Solicite una versión utilizable en react-native

Mmm. Supongo que soy ingenuo al esperar que los módulos de nodo funcionen en react-native. Descubrí que este problema en particular surge porque el empaquetador react-native respeta el campo browser en package.json por lo que se carga la versión del navegador en lugar de la versión del nodo. requerir node-vibrant/lib/index soluciona esto, pero el siguiente error es Requiring unknown module 'fs'

@chetstone ¿Has probado rn-nodeify ? Los módulos de nodo central no funcionarán de forma predeterminada en una aplicación RN porque en realidad no se ejecuta en el nodo (V8), sino en JSC. No es a prueba de balas, pero funciona razonablemente bien en mi experiencia.

Dicho esto, tengo problemas con node-vibrante. ¿Puedes probarlo también y ver dónde llegas? No tengo ningún problema con fs , pero creo que no se están agregando hacks de rn-nodeify para stream en pngjs o módulos de flujo a, solo una corazonada.

Editar: esto podría ser relevante si está relacionado con pngjs: https://github.com/lukeapage/pngjs/issues/64

(Para referencia)

├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├─┬ [email protected]
│ │ │ ├── [email protected]
│ │ │ ├── [email protected]
│ │ │ ├── [email protected]
│ │ │ ├─┬ [email protected]
│ │ │ │ ├── [email protected]
│ │ │ │ └─┬ [email protected]
│ │ │ │   └── [email protected]
│ │ │ ├─┬ [email protected]
│ │ │ │ ├── [email protected]
│ │ │ │ ├─┬ [email protected]
│ │ │ │ │ ├── [email protected]
│ │ │ │ │ └── [email protected]
│ │ │ │ └── [email protected]
│ │ │ └── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├─┬ [email protected]
│ │ │ └── [email protected]
│ │ ├── [email protected]
│ │ └─┬ [email protected]
│ │   └── [email protected]
│ ├── [email protected]
│ └─┬ [email protected]
│   ├── [email protected]
│   └── [email protected]

Mmm. El anterior PL # 21 parece indicar que el nodo vibrante una vez funcionó con React Native.
Todavía no he probado React Native.Pero si carga lib/index.js como script de entrada, la implementación de imagen predeterminada debería ser la de nodejs. (ver https://github.com/akfish/node-vibrant/blob/master/src/index.coffee)
Puede intentar importar la imagen del nodo usted mismo de la siguiente manera:

// var Vibrant = require('node-vibrant')
// var NodeImage = require('node-vibrant/lib/image/node')

// var v = new Vibrant(uri, {Image: NodeImage})

Editar: no importa. Solo vi los comentarios seguidos. Si require('node-vibrant/lib/index') no funciona, el método anterior tampoco lo hará.

Configuraré React Native y haré algunas pruebas una vez que tenga tiempo.

@stovmascript gracias por el React-Nativify, que parece un enfoque prometedor, pero no he tenido tiempo de probarlo. Estoy en otro proyecto en este momento, pero lo analizaré la próxima semana.

@chetstone Cool, a su vez, gracias por el aviso sobre ReactNativity. Solo lo probé y me gusta más. Sin embargo, hay compensaciones.

Con rn-nodeify, casi todo está a tu disposición. Solo debe recordar ejecutar el script postinstall después de instalar nuevos paquetes (es decir, se ejecutará después de npm install , pero no después de npm install some-package --save ). Lo que no es tan bonito es que, a menos que guarde y restaure su package.json antes y después de que rn-nodeify finalice, le agregará un montón de cosas, que básicamente no tiene que estar allí si ha agregado el script postinstall . También entra en sus node_modules y directamente comienza a jugar; por otro lado, si no rompe nada, ¿a quién le importa, se ignora, verdad? He estado usando esta solución hasta ahora y estoy contento con ella.

La solución ReactNativity es IMO más elegante, ya que puede proporcionar su propia función de transformador de paquete al RN Packager (super cool) y puede usar babel-plugin-rewrite-require para cambiar las llamadas require() o import s de módulos de nodo central a sus versiones de navegador durante la compilación. También tiene mucho más control sobre las dependencias: puede instalar todas las versiones del navegador de una sola vez con node-libs-browser o browserify (ambos proporcionan un objeto con asignaciones a las versiones del navegador, que necesitará para configurar el complemento de babel ). Además de eso, puede agregar selectivamente paquetes como react-native-level-fs para el módulo fs. Tendrá que probar a fondo su aplicación con esta solución porque es más propensa a las excepciones en tiempo de ejecución; no todas las bibliotecas de nodos centrales tienen equivalentes en el navegador y rn-nodeify va más allá para tratar de solucionar esto. Lo mismo ocurre con los globales de nodos como process o __dirname - rn-nodeify proporciona un ajuste bastante extenso para estos, pero con la forma ReactNativity, tendrás que mantener tu propio ajuste.

Con ambos métodos, he llegado al mismo punto de pensamiento ...

Después de importar así:

import Vibrant from 'node-vibrant/lib';

Recibo este error:

El prototipo de objeto solo puede ser un objeto o nulo: indefinido

con origen en: _node_modules / hereits / hereits_browser.js: 5_ (versión del navegador del módulo de herencias).

Si actualiza esta función con el nodo que está usando actualmente , activará el nuevo error personalizado:

El superconstructor para "heredar" debe tener un prototipo

Parece estar sucediendo porque el superconstructor que se supone que debe pasarse a esta función no es un constructor, sino una clase instanciada, por lo que cuando cambia el superCtor a: superCtor = superCtor.constructor , funciona.

Siguiendo el stacktrace, conduce al paquete de solicitud utilizado por jimp, pero si es un problema con la solicitud o jimp no usa la solicitud correctamente, no lo sé. Lo más probable es que funcione bien en el nodo, pero solo se rompe cuando se incluye para el navegador o solo para react-native incluso.

Muchas gracias por el informe completo. Entonces, ¿sus modificaciones a _inherits_ son suficientes para que el nodo vibrante funcione con RN o todavía está atascado?

El 6 de noviembre de 2016, 07:24 -0700, Martin Šťovíček [email protected] , escribió:

@chetstone (https://github.com/chetstone) Genial, a su vez, gracias por el aviso sobre ReactNativity. Solo lo probé y me gusta más. Sin embargo, hay compensaciones.

Con rn-nodeify, casi todo está a tu disposición. Solo debe recordar ejecutar el script postinstall después de instalar nuevos paquetes (es decir, se ejecutará después de la instalación de npm, pero no después de la instalación de npm some-package --save). Lo que no es tan bonito es que, a menos que guarde y restaure su package.json antes y después de que rn-nodeify finalice, le agregará un montón de cosas, que básicamente no tiene que estar allí si ha agregado el script postinstall . También entra en sus node_modules y directamente comienza a jugar; por otro lado, si no rompe nada, ¿a quién le importa, se ignora, verdad? He estado usando esta solución hasta ahora y estoy contento con ella.

La solución ReactNativity es IMO más elegante, ya que puede suministrar su propia función de transformador de paquete al RN Packager (super cool) y puede usar babel-plugin-rewrite-require para cambiar las llamadas require () o las importaciones de los módulos del nodo central a sus versiones de navegador durante la compilación. También tiene mucho más control sobre las dependencias: puede instalar todas las versiones del navegador de una sola vez con node-libs-browser o browserify (ambos proporcionan un objeto con asignaciones a las versiones del navegador, que necesitará para configurar el complemento de babel ). Además de eso, puede agregar selectivamente paquetes como react-native-level-fs para el módulo fs. Tendrá que probar a fondo su aplicación con esta solución porque es más propensa a las excepciones en tiempo de ejecución; no todas las bibliotecas de nodos centrales tienen equivalentes en el navegador y rn-nodeify va más allá para tratar de solucionar esto. Lo mismo ocurre con los globales de nodos como process o __dirname: rn-nodeify proporciona un shim bastante extenso para estos, pero con la forma ReactNativity, tendrás que mantener tu propio shim.

Con ambos métodos, he llegado al mismo punto de pensamiento ...

Después de importar así:

importar Vibrant desde 'node-vibrante / lib'

Recibo este error:

El prototipo de objeto solo puede ser un objeto o nulo: indefinido

con origen en: node_modules / hereits / hereits_browser.js: 5 (versión del navegador del módulo de herencias).

Si actualiza esta función con el nodo que está usando actualmente (https://github.com/nodejs/node/blob/master/lib/util.js#L956-L969), activará el nuevo error personalizado:

El superconstructor para "heredar" debe tener un prototipo

Parece estar sucediendo porque el superconstructor que se supone que debe pasarse a esta función no es un constructor, sino una clase instanciada, por lo que cuando cambia el superCtor (https://github.com/isaacs/inherits/blob/master /inherits_browser.js#L3) a: superCtor = superCtor.constructor, funciona.

Siguiendo el stacktrace, conduce al paquete de solicitud utilizado por jimp, pero si es un problema con la solicitud o jimp no usa la solicitud correctamente, no lo sé. Lo más probable es que funcione bien en el nodo, pero solo se rompe cuando se incluye para el navegador o solo para react-native incluso.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub (https://github.com/akfish/node-vibrant/issues/29#issuecomment-258684020), o silencie el hilo (https://github.com/notifications/unsubscribe -auth / AA7l1wl7ggsGTqd7RZlpwWup6T3Ookl7ks5q7eMSgaJpZM4KeOV2).

@stovmascript Finalmente tuve tiempo para probar con react-nativify . No creo que haya llegado tan lejos como tú. Parece que la cantidad de piratería involucrada para que esto funcione podría ser casi infinita.

Primero, no pude hacer funcionar el transformador. Finalmente descubrí que la capacidad de especificar getTransformModulePath() en rn-cli.config.js se eliminó mediante una regresión en mi versión de react-native (0.32.1). Así que solucioné eso usando --transformer en el comando npm start .

Entonces, el empaquetador por alguna razón no pudo encontrar el módulo util a pesar de que estaba instalado. Aún más extraño, parece que podría encontrar util cuando se requiera de algunos módulos ( png.js ) pero no de otros ( _stream_readable ).

Al comentar el requerimiento de util en _stream_readable para ver si podía llegar más lejos, falló cuando jimp refirió a variables que no estaban definidas en process calce.

Finalmente, después de leer este artículo , estoy dispuesto a renunciar a este enfoque. No lo he probado con rn-nodify pero, dada tu experiencia, creo que sería perder más tiempo.

Parece mucho más sencillo construir un contenedor nativo para Android alrededor de la biblioteca de paletas real. No sé Java, pero tal vez sea hora de aprender. Y no funcionará en iOS, pero he estado usando el componente colorgrabber en mi aplicación iOS con mucho éxito. No tan completo como la paleta, pero lo suficientemente bueno para mis propósitos.

Acabo de publicar react-native-palette que envuelve la excelente clase de Android Palette como módulo nativo. El componente también admite una funcionalidad similar para iOS, pero con algunos problemas.

Sería bueno tener también una solución solo de JavaScript, como node-vibrante, que funcionaría en iOS, ya que el soporte nativo es algo deficiente.

Perdón por la larga demora. Pasó la vida real.
Por lo que entiendo por los comentarios anteriores, el problema parece estar relacionado con la referencia de jimp a fs , que no está disponible en el entorno react-native.

Desde la fuente de jimp [1] , si se configura process.env.ENVIRONMENT en "BROWSER" omitirá el módulo fs .

Una posible solución:

// Prevent jimp from requiring `fs`
process.env.ENVIRONMENT = 'BROWSER'
// Require node.js version vibrant explicitly
const Vibrant = require('node-vibrant/lib/index')
// Load image file into a Buffer in some react-native compatible way
let buf = react_native_read_file('path/to/image')
// Pass buffer to node-vibrant
Vibrant.from(buf).getPalette()

¿Alguien podría comprobar si este enfoque funcionará? Gracias.

Un recordatorio de que GitHub tiene 👍 reacciones a los problemas para mostrar apoyo sin obstruir el hilo

Su última versión "3.2.0-alpha" se bloquea en React Native con el error "No se puede encontrar la variable: yo"
y después de eliminar solo 1 cadena:
import * as Vibrant from 'node-vibrant';
La aplicación funciona, por lo que ni siquiera hay posibilidad de probarla en React Native.

Su última versión "3.2.0-alpha" se bloquea en React Native con el error _ "No se puede encontrar la variable: self" _
y después de eliminar solo 1 cadena:
import * as Vibrant from 'node-vibrant';
La aplicación funciona, por lo que ni siquiera hay posibilidad de probarla en React Native.

Lo siento, realmente no lo entiendo, ¿la biblioteca de nodo vibrante funciona con RN o no?

@Psiiirus debería estar funcionando en la compilación no alfa

Obtengo Can't find variable: document en react-native.