Pixi.js: PRECISA-SE DE AJUDA: Esforço de conversão ES6

Qual rota você quer descer com let e const? Padrão para const, e use apenas let para propriedades que devem ter sua referência alterada
Ou
Padrão para deixar, e só use const como mais uma dica para o desenvolvedor que eles, estou falando sério, não mudam isso.

A primeira opção. Padrão para usar const. Eu converti todos os vars internos para permitir e corrigi problemas óbvios de escopo e não permiti o uso de var com jshint. Precisa de outro passe com const.

Coisas que eu recomendaria:

• [x] Use babel-preset-es2015-loose , eu tive um desempenho ruim apenas com babel-preset-es2015.
• [x] Mude para eslint , ele tem melhor suporte a ES6 e é melhor que jshint em geral. Aqui está um bom ponto de partida para o estilo do pixi. Ele também reclamará de lugares em que você poderia usar const mas usou let . Facilita a localização de todos os lugares que você precisa corrigir para const.
• [x] Use o mestre mais recente do jsdoc, ele tem muitas correções do ES6 que ainda não foram lançadas.
• Mude para webpack.

Obrigado @englercj. Boa lista.

@englercj O babel-preset-es2015-loose tem um aviso de descontinuação, você tentou babel-preset-es2015 com a opção {"loose": true} como sugere?

Eu também prefiro webpack a browserify, alguns links úteis:
https://github.com/webpack/webpack/tree/master/examples/multi-part-library
http://krasimirtsonev.com/blog/article/javascript-library-starter-using-webpack-es6

Minhas preferências é esperar no webpack e não empilhar isso. Potencialmente para outro PR menor. Essa mudança representa uma mudança no processo de construção, mas não necessariamente uma melhoria no ES6. Além disso, precisaria garantir que os mapas de origem, cabeçalhos etc. funcionem. Eu entendo como é melhor, mas vamos esperar por isso por enquanto.

O babel-preset-es2015-loose tem um aviso de descontinuação, você tentou babel-preset-es2015 com a opção {"loose": true} como sugere?

Ha, isso foi _apenas_ adicionado 2 semanas atrás. Eu não tentei isso porque não existia no momento em que comecei a usá-lo.

Olá a todos,

Apenas um grito rápido para ecoar o pensamento de Chad sobre o modo solto, e adicionar meus dois centavos aqui.
Como discutimos com @GoodBoyDigital antes de termos muito cuidado com o desempenho, acho que o modo solto é um bom ponto de partida.

Além disso, não tenho certeza de quão atualizada esta tabela é: https://kpdecker.github.io/six-speed/ vocês sabem?

Se ainda for, temos que ter cuidado para não enlouquecer o ES2015 e converter coisas que não precisam ser, ou seja: se for-of ainda reduzir o desempenho como diz na mesa, não devemos • use-o ao iterar filhos do grafo de cena.

O Babel agora deve otimizar for-of para arrays (veja: Optimization ), esses testes parecem ser bem antigos .

Enfim, @alvinsight você está certo, nem tudo precisa ser ES2015.

Boa lista @englercj !

Também acordado com @alvinsight. Já estamos vendo um código muito mais limpo com a sintaxe es6, ganhando tudo :)

Todas as outras decisões devem ser baseadas no desempenho - 'Parece melhor, mas corre mais devagar - não faça isso'

O loop de matriz é um bom exemplo - não há necessidade de substituir coisas que já são rápidas e legíveis apenas porque podemos.

Também sim para webpack! @bigtimebuddy está correto, essa deve ser a segunda parte desta mudança para es6.

Acordado!
É muito melhor finalmente poder ler e escrever class Sprite extends Container !

Atualizada

• Substituído jshint por eslint (e erros de linting corrigidos, eslint para a vitória!)
• Usando loose: true com babel-preset-es2015

Tarde tudo!

Bata um pouco shnag com nossos mixins ..

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

O acima não está funcionando atualmente na ramificação ES6, então coisas como interação são interrompidas.

Existe uma boa maneira de fazer isso com classes es6?

Respostas em um cartão postal, por favor!

Ok, eu estava certo da primeira vez - o código acima não está funcionando atualmente .. (Posso culpar o fato de ser sexta à noite?)

Acho que é aqui que a composição brilha!

Hmm, o que não está funcionando? Isso funcionou para mim:

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

Copie e cole isso no console do Chrome e parece funcionar bem.

Interessante! Atualmente a interação não está funcionando e as propriedades interativas parecem estar faltando. Talvez outro motivo? Vai continuar cavando...

Ah há! Encontrei

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

import interactiveTarget from './interactiveTarget';

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

Pode ser?

sim!

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

Ele corrige alguns bits, como os mixins e o texto.

Amanhã vou ver os filtros...

Parecendo muito bom embora rachaduras!

Bom trabalho! Sim, usar require() assim retornaria um objeto com uma única chave padrão contendo tudo o que você esperava.

Filtros com bom aspecto agora! Executei isso em um projeto atual no qual estou trabalhando que é bastante complexo - e tudo parece funcionar 100%!

Pode testá-lo em alguns outros jogos, mas deve ser bom mesclar em breve!

@bigtimebuddy você já tentou esta compilação com pixi-animate?

Jogando isso lá fora... traceur parece mais rápido que babel?
Vale a pena investigar?

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

Esses testes são antigos, e não rodam com babel solto. Além disso, você também pode argumentar que, em muitos casos, o texto datilografado é mais rápido que os dois :)

Vou sugerir a vocês que considerem o uso do TypeScript como parte desta grande reescrita/adaptação. Apenas alguns pontos sobre o TypeScript:

• Usar o sistema de tipos em JavaScript se tornará o novo padrão, é apenas uma questão de tempo.
• É JavaScript. Nenhuma diferença na sintaxe além do sistema de tipos.
• Melhora a qualidade do código. Você possivelmente encontrará uma quantidade considerável de código que precisa ser ligeiramente reestruturado para corresponder aos tipos nos lugares certos.
• Aumente a verificação de qualidade da solicitação de pull - se houver algum problema de tipo, o patch simplesmente não poderá ser mesclado.

Sei que não é uma tarefa fácil, mas acredito que pode trazer grandes benefícios para a base de código e para a comunidade.
Felicidades!

@endel Estou movendo pixi-spine para typescript, haverá demos de plugins TS para pixi.

@endel apenas curioso, mas o TS resolveu o problema que tinha quando olhei pela última vez: que é uma situação de tudo ou nada quando se trata da saída, ou seja, _tudo_ é transpilado de volta para ES5, ou nada é, com base no destino ?

Lembro que não usava polyfills. Portanto, se você deseja que uma única base de código seja executada em uma ampla variedade de navegadores, desde o mais avançado até o legado, você ainda precisa direcionar o ES5 e todos os novos recursos interessantes, que os navegadores modernos agora suportam nativamente, são ignorados porque ele faz downgrade para ES5 de qualquer maneira? Ou ainda é o caso em que você precisa usar um polyfill ES6 no topo da saída TS para cobrir todas as bases?

que é uma situação de tudo ou nada quando se trata de saída, ou seja, tudo é transpilado de volta para ES5, ou nada é, com base no destino?

Não sei o que você quer dizer com isso. Se você direcionar o ES5, ele transpilará a sintaxe para o ES5. Mas o mesmo acontece com babel, tracuer, et al. Há algo específico que você está se referindo?

Lembro que não usava polyfills.

Não, mas também não babel, tracuer ou outros transpilers; então eu não tenho certeza do que você está dirigindo? Teríamos que usar polyfills core-js de qualquer maneira (babel ou TS).

Acho que a discussão é babel para transformar ES6 -> ES5 ou TypeScript para transformar TS -> ES5. Temos que ir ES5 de qualquer maneira. O TS pode direcionar o ES6 e poderíamos enviar uma compilação ES6 se quiséssemos, mas seria além da compilação ES5.

@photonstorm Com o TypeScript, até onde eu sei, você não pode escolher recursos para transpilar para ES5 como você pode fazer com o Babel.

Eu uso o TypeScript e acho incrível. Adoraria ver Pixi adotar eventualmente. O Google agora está incentivando os desenvolvedores a usar o TypeScript com o Angular, o que é um bom sinal de ampla adoção. Para uma base de código tão complexa quanto o Pixi, seria bem servido por tipagens estritas.

Alguns problemas que precisariam ser resolvidos com o TypeScript incluem jsdocs (alguém tem experiência com isso?) e dependências upstream que podem estar usando o src quando require('pixi.js') (alguém está exigindo isso?).

Como primeiro passo, migrar para o ES6 ainda é uma boa opção, já que precisaremos converter para classes de qualquer maneira. Poderíamos considerar o TypeScript outro "passe" na modernização da base de código assim que tivermos certeza de que todas as preocupações podem ser abordadas.

Com o TypeScript, até onde eu sei, você não pode escolher recursos para transpilar para ES5 como você pode fazer com o Babel.

Eu não tinha ideia de que você poderia fazer isso com Babel. Não tenho certeza se vejo o benefício disso para nós, já que temos que direcionar o ES5 de qualquer maneira. Mas isso é legal!

Alguns problemas que precisariam ser resolvidos com o TypeScript incluem jsdocs

https://github.com/TypeStrong/typedoc

upstream-dependencies que podem estar usando o src quando require('pixi.js') (alguém está precisando assim?).

Podemos apontar "main" para qualquer coisa que quisermos, e com typescript você aponta para os arquivos construídos (não para o _bundle_). Por exemplo, arquivos TS vão para src/ e você transpila cada arquivo para js/ ou algo assim, então aponta main para lá. Em seguida, também agrupamos tudo e colocamos os pacotes em dist/ ou w/e. O pacote npm vem com os arquivos js/tsd, mas normalmente não com a fonte TS (discutível).

Como primeiro passo, migrar para o ES6 ainda é uma boa opção, já que precisaremos converter para classes de qualquer maneira. Poderíamos considerar o TypeScript outro "passe" na modernização da base de código assim que tivermos certeza de que todas as preocupações podem ser abordadas.

👍

Com o TypeScript, até onde eu sei, você não pode escolher recursos para transpilar para ES5 como você pode fazer com o Babel.

Eles adicionaram esse recurso no TypeScript 2.0: https://github.com/Microsoft/TypeScript/wiki/What 's-new-in-TypeScript#inclusive-built-in-type-declarations-with---lib

É comum usar ES5 como destino, mas incluir ES6 como bibliotecas, para ter as definições de tipo para coisas como Symbol , Map , etc.

De fato, como @englercj disse, você precisa incluir shims depois que seu código for compilado, não importa qual compilador você esteja usando. O Babel não inclui um polyfill Symbol para IE9 automaticamente, por exemplo.

Eu não tinha ideia de que você poderia fazer isso com Babel. Não tenho certeza se vejo o benefício disso para nós, já que temos que direcionar o ES5 de qualquer maneira. Mas isso é legal!

Para o Pixi, não é tão útil, mas sim, você pode escolher as predefinições do Babel para selecionar apenas determinados recursos para transpilar. Isso pode ser útil se você deseja compilar para ES6, mas deseja apenas oferecer suporte a recursos V8 de ponta no Node 6, Electron 1, etc.

É realmente um paradoxo interessante. Use ES6 para construir, porque é limpo, adorável e muito bem suportado/otimizado internamente pelos navegadores modernos. No entanto, destrua todo esse trabalho árduo transpilando como se fosse 1995 :) (e com mudanças na sintaxe da linguagem você não pode contornar isso).

Eu aprecio o problema é universal, nada a ver com TS ou Pixi. Apenas uma situação um pouco estranha para se estar.

@photonstorm É uma ironia infeliz 😞 espero que possamos ter compilações ES6 e ES5 para que, para aplicativos empacotados (como o elétron), eles possam usar a compilação ES6.

Apenas pulando para a discussão aqui :) Eu vi pessoas transpilarem TS para ES6 e depois usarem Babel para transpilar para ES5, eu acho que se você quiser algo como certos recursos transpilados, isso seria muito bom?

Além disso, existe (ainda outro...) módulo bundler por aí, no entanto, acho que este parece produzir um código bastante liso, com a possibilidade de várias saídas.
http://rollupjs.org/ ele agrupa a sintaxe do módulo ES6/ES2015, o que eu acho que é muito bom se você quiser testar o código no futuro.

eu sou +1 para PIXI sendo escrito em Typescript. Pela minha experiência, o tipo realmente ajuda muito com a estrutura de projetos como este. Se ao menos puder ser mantido em desempenho :)

RollUp é fantástico, adoro usá-lo. Seu tremor de árvore é seriamente inteligente. Usado com bubel (em vez de babel), ele cria um fluxo de trabalho muito, _realmente_ rápido.

Interessante ver tanto amor TS aqui. Certamente não era o caso há um ano :) Existem maneiras de digitar a verificação ES2015 que podem valer a pena considerar.

@photonstorm não encontrou bubel, mas tem "buble"

Sim, sim, erro de digitação. http://buble.surge.sh/

BubleTape é um bom equipamento de teste para isso https://github.com/snuggs/buble-tape

O nº 2936 é a razão pela qual os membros deixaram os documentos? Este tem um membro exposto, onde este tem 25+.

@memberof precisa ser adicionado a eles agora, ou existe alguma mágica que pode ser aplicada?

@staff0rd Acho que ainda estamos limpando as coisas, assim que estabilizar um pouco, analisaremos a limpeza dos documentos. Provavelmente é apenas porque a versão jsdoc que estamos usando tem bugs do ES6. Devemos ser capazes de limpar isso em breve.

ES6 foi mesclado para dev , obrigado a todos que ajudaram. Isso é muito apreciado!

Fechando isso por enquanto.

Este tópico foi bloqueado automaticamente, pois não houve nenhuma atividade recente depois que ele foi fechado. Por favor, abra um novo problema para bugs relacionados.