Pixi.js: SE SOLICITA AYUDA: Esfuerzo de conversión de ES6

¿Qué ruta quieres seguir con let y const? Predeterminado a const, y solo use let para propiedades cuya referencia debería cambiarse
O
Predeterminado para permitir, y solo use const como una pista más para el desarrollador de que, lo digo en serio, no cambie esto.

La opción anterior. Predeterminado para usar const. Convertí todos los vars internos a let y arreglé problemas de alcance obvios y deseché el uso de var con jshint. Necesita otro pase con const.

Cosas que recomendaría:

• [x] Use babel-preset-es2015-loose , tuve un desempeño pobre solo con babel-preset-es2015 solo.
• [x] Cambie a eslint , tiene mejor compatibilidad con ES6 y es mejor que jshint en general. Aquí hay un buen punto de partida para el estilo de pixi. También se quejará de los lugares en los que podría usar const pero usó let . Hace que sea fácil encontrar todos los lugares que necesita para arreglar para const.
• [x] Use el último maestro de jsdoc, tiene muchas correcciones de ES6 que aún no se han lanzado.
• Cambiar a paquete web.

Gracias @englercj. Buena lista.

@englercj Babel-preset-es2015-loose tiene una advertencia de obsolescencia, ¿probó babel-preset-es2015 con la opción {"loose": true} como sugiere?

También prefiero webpack a browserify, un par de enlaces útiles:
https://github.com/webpack/webpack/tree/master/examples/multi-part-library
http://krasimirtsonev.com/blog/article/javascript-library-starter-using-webpack-es6

Mis preferencias son esperar en el paquete web y no acumularlo. Potencialmente para otro PR más pequeño. Ese cambio representa un cambio en el proceso de compilación, pero no necesariamente una mejora de ES6. Además, necesitaría asegurarse de que los mapas fuente, los encabezados, etc. funcionen. Entiendo cómo es mejor, pero esperemos eso por ahora.

Babel-preset-es2015-loose tiene una advertencia de obsolescencia, ¿probó babel-preset-es2015 con la opción {"loose": true} como sugiere?

Ja, eso fue _recién_ agregado hace 2 semanas. No lo he probado porque no existía en el momento en que comencé a usarlo.

Hola a todos,

Solo un grito rápido para hacerme eco del pensamiento de Chad sobre el modo suelto, y agregar mis dos centavos aquí.
Como discutimos con @GoodBoyDigital antes, debemos tener mucho cuidado con el rendimiento, por lo que creo que el modo suelto es un buen punto de partida.

Además, no estoy seguro de cuán actualizada está esta tabla: https://kpdecker.github.io/six-speed/ ¿lo saben?

Si todavía lo es, debemos tener cuidado de no volvernos locos con ES2015 y convertir cosas que no necesitan serlo, es decir: si for-of todavía reduce el rendimiento como dice en la tabla, no deberíamos. No lo use al iterar gráficos de escenas secundarios.

Babel ahora debería optimizar for-of para matrices (ver: Optimización ), esas pruebas parecen ser bastante antiguas .

De todos modos, @alvinsight tienes razón, no todo tiene que ser ES2015.

¡Buena lista @englercj !

También estuvo de acuerdo con @alvinsight. Ya estamos viendo un código mucho más limpio con la sintaxis es6, por lo que ganamos en general :)

Todas las demás decisiones deben basarse en el rendimiento: "¿Se ve mejor pero funciona más lento? No lo hagas".

Array looping es un buen ejemplo: no hay necesidad de reemplazar cosas que ya son rápidas y legibles solo porque podemos.

¡También sí al paquete web! @bigtimebuddy tiene razón, esa debería ser la segunda parte de este cambio a es6.

¡Acordado!
¡Es mucho mejor poder finalmente leer y escribir class Sprite extends Container !

Actualizado

• Se reemplazó jshint con eslint (y se corrigieron los errores de pelusa, ¡eslint para ganar!)
• Usando loose: true con babel-preset-es2015

Tardes a todos!

Dale un pequeño golpe con nuestros mixins..

Object.assign(
    core.DisplayObject.prototype,
    require('./interactiveTarget')
);

Lo anterior no funciona actualmente en la rama ES6, por lo que cosas como la interacción están rotas.

¿Hay una buena manera de hacer esto con las clases de es6?

¡Respuestas en una postal por favor!

Ok, tenía razón la primera vez: el código anterior no funciona actualmente ... (¿Puedo culpar a esto por el hecho de que es viernes por la noche?)

¡Creo que aquí es donde brilla la composición!

Hmm, ¿qué no está funcionando? Esto funcionó para mí:

class MyThing {}
Object.assign(MyThing.prototype, { newFn: function () { console.log('mix'); } });
var mything = new MyThing();
mything.newFn(); // logs: "mix"

Copie y pegue eso en la consola de Chrome, y parece funcionar bien.

¡Interesante! Actualmente, la interacción no funciona y parece que faltan propiedades interactivas. ¿Quizás otra razón? Seguire cavando...

¡Ajá! Lo encontré

Object.assign(
    core.DisplayObject.prototype,
    require('./interactiveTarget') <--- this is a require!
);

import interactiveTarget from './interactiveTarget';

Object.assign(
    core.DisplayObject.prototype,
    interactiveTarget
);

¿Quizás?

¡Sip!

PR 1 aquí: https://github.com/pixijs/pixi.js/pull/2960

Arregla algunos bits como los mixins y el texto.

Mañana miraré los filtros...

¡Se ve muy bien, aunque caps!

¡Buen trabajo! Sí, usar require() como ese devolvería un objeto con una única clave predeterminada que contiene todo lo demás que esperabas.

¡Los filtros se ven bien ahora! Ejecuté esto en un proyecto actual en el que estoy trabajando que es bastante complejo, ¡y todo parece funcionar al 100%!

Podría probarlo en algunos otros juegos, ¡pero debería ser bueno fusionarlo muy pronto!

@bigtimebuddy , ¿has probado esta compilación con pixi-animate?

Tirando esto por ahí... ¿traceur parece más rápido que babel?
¿Vale la pena investigar?

https://kpdecker.github.io/six-speed/

Esas pruebas son viejas y no se ejecutan con babel suelto. Además, también podría argumentar que, en muchos casos, TypeScript es más rápido que ambos :)

Les sugiero que consideren usar TypeScript como parte de esta importante reescritura/adaptación. Solo algunos puntos sobre TypeScript:

• Usar el sistema de tipos en JavaScript se convertirá en el nuevo estándar, es solo cuestión de tiempo.
• ES JavaScript. No hay diferencia en la sintaxis además del sistema de tipos.
• Mejora la calidad del código. Posiblemente encontrará una cantidad considerable de código que debe reestructurarse ligeramente para que coincida con los tipos en los lugares correctos.
• Aumente la verificación de calidad de la solicitud de extracción: si hay algún tipo de problema, el parche simplemente no se puede fusionar.

Sé que no es una tarea fácil, pero creo que puede traer grandes beneficios para la base de código y la comunidad.
¡Salud!

@endel Estoy moviendo pixi-spine a mecanografiado, habrá demostraciones de complementos TS para pixi.

@endel solo tiene curiosidad, pero TS resolvió el problema que tenía la última vez que lo miré: que es una situación de todo o nada en lo que respecta a la salida, es decir, _todo_ se vuelve a transpilar a ES5, o nada, según el objetivo ?

Recuerdo que no usó polyfills en absoluto. Entonces, si desea que una sola base de código se ejecute en una amplia gama de navegadores, desde los más avanzados hasta los heredados, aún debe apuntar a ES5, y todas las funciones nuevas y agradables, que los navegadores modernos ahora admiten de forma nativa, se ignoran porque se degrada a ES5 de todos modos? ¿O sigue siendo el caso en el que necesita usar un polyfill ES6 encima de la salida TS para cubrir todas las bases?

que es una situación de todo o nada cuando se trata de la salida, es decir, todo se vuelve a transpilar a ES5, o nada, según el objetivo?

No estoy seguro de lo que quieres decir con esto. Si apunta a ES5, transpila la sintaxis a ES5. Pero también babel, tracuer, et al. ¿Hay algo específico a lo que te refieres?

Recuerdo que no usó polyfills en absoluto.

No lo hace, pero de nuevo tampoco babel, tracuer u otros transpilers; así que no estoy seguro de a qué te diriges? Tendríamos que usar polyfills core-js de cualquier manera (babel o TS).

Creo que la discusión es babel para transformar ES6 -> ES5 o TypeScript para transformar TS -> ES5. Tenemos que ir ES5 de cualquier manera. TS puede apuntar a ES6, y podríamos enviar una compilación de ES6 si quisiéramos, pero sería además de la compilación de ES5.

@photonstorm Con TypeScript, hasta donde yo sé, no puede seleccionar y elegir características para transpilar a ES5 como puede hacerlo con Babel.

Uso TypeScript y creo que es increíble. Me encantaría ver a Pixi adoptar eventualmente. Google ahora está alentando a los desarrolladores a usar TypeScript con Angular, lo cual es una buena señal de una adopción generalizada. Para una base de código tan compleja como Pixi, estaría bien servida por tipos estrictos.

Algunos problemas que deberían abordarse con TypeScript incluirían jsdocs (¿alguien tiene experiencia con esto?) y dependencias ascendentes que podrían estar usando el src cuando require('pixi.js') (¿alguien necesita algo así?).

Como primer paso, pasar a ES6 sigue siendo una buena opción, ya que de todos modos necesitaremos convertirnos a clases. Podríamos considerar TypeScript como otro "paso" en la modernización de la base de código una vez que estemos seguros de que se pueden abordar todas las inquietudes.

Con TypeScript, según mi leal saber y entender, no puede seleccionar y elegir funciones para transpilar a ES5 como puede hacerlo con Babel.

No tenía idea de que pudieras hacer eso con babel. No estoy seguro de ver el beneficio de esto para nosotros, ya que tenemos que apuntar a ES5 de todos modos. ¡Pero eso es genial!

Algunos problemas que deberían abordarse con TypeScript incluirían jsdocs

https://github.com/TypeStrong/typedoc

Dependencias ascendentes que podrían estar usando el src cuando requieren ('pixi.js') (¿alguien necesita algo así?).

Podemos apuntar "principal" a lo que queramos, y con mecanografiado lo apunta a los archivos creados (no al _paquete_). Por ejemplo, los archivos TS van a src/ y usted transpila cada archivo a js/ o algo así, luego apunta principal allí. Luego también empaquetamos todo y colocamos los paquetes en dist/ o w/e. El paquete npm se envía con los archivos js/tsd, pero normalmente no con la fuente TS (discutible).

Como primer paso, pasar a ES6 sigue siendo una buena opción, ya que de todos modos necesitaremos convertirnos a clases. Podríamos considerar TypeScript como otro "paso" en la modernización de la base de código una vez que estemos seguros de que se pueden abordar todas las inquietudes.

👍

Con TypeScript, según mi leal saber y entender, no puede seleccionar y elegir funciones para transpilar a ES5 como puede hacerlo con Babel.

Agregaron esta característica en TypeScript 2.0: https://github.com/Microsoft/TypeScript/wiki/What 's-new-in-TypeScript#incluyendo-construido-en-type-declarations-with---lib

Es habitual usar ES5 como destino pero incluir ES6 como bibliotecas, para tener las definiciones de tipo para cosas como Symbol , Map , etc.

De hecho, como dijo @englercj , debe incluir correcciones después de compilar su código, sin importar qué compilador esté usando. Babel no incluye un polyfill de Symbol para IE9 automáticamente, por ejemplo.

No tenía idea de que pudieras hacer eso con babel. No estoy seguro de ver el beneficio de esto para nosotros, ya que tenemos que apuntar a ES5 de todos modos. ¡Pero eso es genial!

Para Pixi, no es tan útil, pero sí, puede elegir los ajustes preestablecidos de Babel para seleccionar solo ciertas funciones para transpilar. Esto puede ser útil si desea compilar en ES6 pero solo desea admitir funciones V8 de última generación en Node 6, Electron 1, etc.

Realmente es una paradoja interesante. Use ES6 para compilar, porque es limpio, encantador y muy bien compatible / optimizado internamente por los navegadores modernos. Sin embargo, destruya todo ese arduo trabajo al transpilar como si fuera 1995 :) (y con los cambios de sintaxis del idioma no puede cambiar esto).

Agradezco que el problema sea universal, nada que ver con TS o Pixi. Es una situación un poco rara en la que estar.

@photonstorm Es una ironía desafortunada 😞 espero que podamos tener compilaciones ES6 y ES5 para que las aplicaciones empaquetadas (como electron) puedan usar la compilación ES6.

Solo saltando a la discusión aquí :) He visto a personas transpilar TS a ES6 y luego usar Babel para transpilarlo a ES5, supongo que si desea transpilar ciertas funciones, ¿sería bastante bueno?

Además, hay (otro más...) paquete de módulos, sin embargo, creo que este parece producir un código bastante ingenioso, con la posibilidad de múltiples salidas.
http://rollupjs.org/ incluye la sintaxis del módulo ES6/ES2015, lo que supongo que es bastante bueno si desea probar el código en el futuro.

Soy +1 para que PIXI esté escrito en Typescript. Desde mi experiencia, el tipo realmente ayuda mucho con la estructura de proyectos como este. Si tan solo se puede mantener en funcionamiento :)

RollUp es fantástico, me encanta usarlo. Su sacudida de árboles es muy inteligente. Usado con bubel (en lugar de babel) hace que el flujo de trabajo sea muy, muy rápido.

Es interesante ver tanto amor de TS aquí. Ciertamente no era el caso hace un año :) Hay formas de escribir la verificación ES2015 que puede valer la pena considerar.

@photonstorm no encontró bubel, pero hay "buble"

Sí, sí, error tipográfico. http://buble.surge.sh/

BubleTape es un buen arnés de prueba para ello https://github.com/snuggs/buble-tape

¿Es el n.º 2936 el motivo por el que los miembros dejaron los documentos? Esto tiene un miembro expuesto , donde tiene más de 25.

¿Es necesario agregarles @memberof ahora, o hay alguna magia que se pueda aplicar?

@staff0rd Creo que todavía estamos limpiando las cosas, una vez que se estabilice un poco, buscaremos limpiar los documentos. Lo más probable es que sea solo porque la versión de jsdoc que estamos usando tiene errores de ES6. Deberíamos poder ponernos a limpiar esto pronto.

ES6 se fusionó con dev , gracias a todos los que ayudaron. ¡Es muy apreciado!

Cerrando esto por ahora.

Este hilo se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema para los errores relacionados.