Xterm.js: Introduire un système de build pour activer plus d'un fichier js

Je suis entièrement d'accord avec cela. Allons-y après avoir terminé la documentation et publié la version 1.0.0.

Je suggère webpack ( prototype ici ) car je l'ai déjà utilisé et il fait exactement ce que nous voulons (regroupe plusieurs fichiers en 1 en utilisant require() ). J'ai également à peine touché à la surface de ses capacités et c'est très populaire.

Une autre option est TypeScript que j'aime beaucoup après avoir travaillé sur vscode. Cela permettrait à plusieurs fichiers d'être intégrés en un seul et fournirait une sécurité de type qui favoriserait la qualité du code (particulièrement bonne car les tests unitaires sont inégaux).

Je pense que le simple ES6 ou TypeScript sont plus adaptés à cela. Webpack semble être plus exagéré en ce moment.

La chose la plus importante que nous devons prendre en compte est de savoir comment expédier le code ici. Cela introduira très probablement des changements de rupture (en particulier pour les utilisateurs de Bower), car nous devrons trouver un moyen d'expédier les artefacts construits pour que cette bibliothèque fonctionne dans le navigateur hors de la boîte.

J'ajoute ceci au jalon "ouvert" pour la version 2.0 et commence quelques expérimentations à ce sujet, de préférence avec un ES6 simple, qui est proche de TypeScript.

Mes principales préoccupations avec TypeScript sont :

1. barrière à l'entrée pour les nouveaux contributeurs
2. aucun des autres responsables n'a travaillé avec TypeScript dans le passé (si je me souviens bien), moi inclus

Lorsque vous utilisez bower, la plupart des projets avec un système de construction, ajoutez les fichiers construits dans un répertoire dist et ce sont ceux auxquels vous vous connectez. Cela introduirait une rupture, donc la v2 serait appropriée.

+1 pour l'utilisation de Typescript. Aucune idée de l'état actuel du support ES6, je pense que les générateurs sont encore à un stade précoce dans certains moteurs JS et donc pas encore utilisables.

Je vais me charger de mettre sur pied un prototype TypeScript.

Puis-je vous suggérer de commencer par ES6 & Babel ? Tirer parti de la dactylographie est une bonne chose, mais cela aura un prix.

Avoir un projet es6 permettra à votre utilisateur de simplement "var Terminal = require('xterm')" et d'utiliser le code source brut (navigateur fonctionnera très bien)". Avec le typescript, vous aurez un fichier différent pour la construction et la source de votre demande.

De plus, grâce à la conception dactylographiée, un projet ES6 est, de facto, compatible dactylographié. La migration complète vers dactylographié peut se faire en une deuxième étape (et très fluide).

Puis-je aider ici ?

Sourcemaps contourne cela si nécessaire, la sécurité de type est le principal avantage imo.

Il ne s'agit pas de la sourcemap, mais de n'avoir aucune étape de "construction" requise pour ceux qui utilisent simplement browserify (ES6 est déjà pris en charge dans la plupart des navigateurs modernes)

@ 131 en raison de Bower, nous serions probablement en train de valider la version compilée dans un répertoire dist ou out .

Est-ce que je peux essayer une version es6 ? (j'ai joué un peu)
avec une sortie compilée bower dans /dist , bien sûr !

Les changements les plus prometteurs dans ES6 ne peuvent pas être remplis par babel - les concepts d'itérateur/générateur/compréhension. Votez pour l'idée vanille ES6, en raison de l'état actuel de l'ES6 dans les moteurs JS couramment utilisés. Et j'espère toujours des annotations de type facultatives dans certaines versions ultérieures de JS ...

La prise en charge de Babel pour le générateur est complète (préréglage babel es2015) et fonctionne parfaitement avec co , pourtant, le code actuel n'en gagne pas beaucoup.

J'ai une succursale en cours https://github.com/sourcelair/xterm.js/pull/245

Comme j'ai abandonné fetch, aucune promesse n'est laissée pour l'instant (il est donc difficile de faire une démo de générateurs), mais si vous le souhaitez, je peux facilement configurer une version fonctionnelle avec generator & promise (dites-moi simplement sur quel événement / opération )

D'accord, alors permettez-moi de contribuer à cela.

Tout d'abord convenons que dans la version 2.0 (après avoir migré vers l'une ou l'autre option) :

1. l'API publique pour l'importation de cette bibliothèque se brisera
2. nous expédierons un monolithe prêt pour le navigateur pour le noyau et les fichiers prêts pour le navigateur pour les modules complémentaires

Ce sont des prérequis pour rendre l'utilisation de cette bibliothèque aussi simple que possible, tout en la rendant plus facile à maintenir.

Ensuite, permettez-moi de répondre à autant de commentaires que possible :

À propos des générateurs

Je pense que les générateurs sont encore à un stade précoce dans certains moteurs JS et donc pas encore utilisables.

@jerch comme @131 mentionné, les générateurs sont entièrement pris en charge dans babel polyfill : http://babeljs.io/docs/learn-es2015/#generators. Cela ne nous concerne en aucun cas, car nous n'utilisons pas de générateurs pour le moment et il n'y a pas de problème ouvert qui pourrait bénéficier des générateurs. Donc, de toute façon, nous ne les utiliserons pas de sitôt (jusqu'à ce que nous devions le faire).

À propos de l'importation (TypeScript vs ES6)

Avoir un projet es6 permettra à votre utilisateur de simplement "var Terminal = require('xterm')" et d'utiliser le code source brut (navigateur fonctionnera très bien)". Avec le typescript, vous aurez un fichier différent pour la construction et la source de votre demande.

Sourcemaps contourne cela si nécessaire, la sécurité de type est le principal avantage imo.
@ 131 en raison de Bower, nous serions probablement en train de valider la version compilée dans un répertoire dist ou out.

@131 , je suis d'accord avec @Tyriar ici. Toute personne qui utilisera xterm.js aura accès aux fichiers construits car elle récupérera une version d'une bibliothèque publiée dans npm, bower ou GitHub avec les artefacts construits inclus.

À propos de TypeScript vs ES6

Bien que personnellement, je ne sois pas encore décidé quelle est la meilleure solution, je penche légèrement vers vanilla ES6 pour les raisons suivantes (la plupart d'entre elles mentionnées dans https://github.com/sourcelair/xterm.js/issues/158#issuecomment- 241406631):

• À l'exception de @Tyriar, aucun des responsables n'a jamais travaillé avec TypeScript.
• TypeScript pourrait introduire une barrière à l'entrée pour les (nouveaux) contributeurs.
• TypeScript peut être exagéré pour ce que ce problème tente de résoudre. Le problème actuel est de "Introduire un système de build pour activer plus d'un fichier js ". Ceci peut être réalisé avec de simples ES6 et Babel et rien de plus. Bien que la sécurité de type soit le plus grand avantage de TypeScript, je ne sais pas encore si cette base de code a besoin d'une sécurité de type.

Malgré les arguments ci-dessus, je suis vraiment ouvert à passer à TypeScript, car créer une base de code fiable et à l'épreuve du temps est toujours une bonne idée. Il suffit de peser le pour et le contre.

Enfin, comme je n'ai pas d'expérience significative avec ES6 et TypeScript, je voudrais ❤️ voir les deux prototypes et contribuer à la conversation des deux. Alors merci beaucoup @Tyriar et @131 d' avoir proposé de créer des prototypes 🎉 .

PS : J'ai déjà commencé à lire sur TypeScript et ES6, afin de fournir des commentaires plus constructifs et d'aider à prendre une décision appropriée.

J'ai mis à jour mon PR, avec un dossier /dist/ fonctionnel (avec une démo côté client fonctionnelle, aucun serveur requis). , veuillez regarder l' arborescence du

npm run start pour la démo côté serveur fonctionne également.

Concernant @parisk , pour 1 : l'API publique d'import de cette librairie va casser
Nous pouvons toujours faire un mouvement très stratégique et avoir, avant le dossier "/dist/" renommé "/src/" , afin de ne rien casser.

@Tyriar , @parisk , @jerch je suppose que j'ai fini, maintenant,

Concernant les addons, je pense qu'ils devraient être divisés en d'autres dépôts dans l'organisation xtermjs, cela facilite leur inclusion (installez le dep et l'exigez), favorise la séparation et en fait des exemples plus clairs sur la façon d'écrire un addon.

Cela dit, ils utilisent actuellement des API privées, donc si tel était le cas, nous devrions exposer des API publiques qui leur permettent de faire ce genre de choses.

TypeScript PR est disponible sur https://github.com/sourcelair/xterm.js/pull/247

Eh bien, mes informations sur le support du générateur de babel semblent obsolètes. Pourquoi je l'ai proposé - les générateurs en tant que coroutines sont un bon moyen de travailler avec des données rationalisées. Cette technique est souvent utilisée pour la séparation de code en Python. (Je pense que les générateurs dans ES6 sont fortement influencés par Python.)

xterm.js pourrait en bénéficier en divisant l'objet Terminal en morceaux de responsabilités. En particulier, l'analyseur syntaxique pourrait être facilement séparé de la gestion de l'état terminal avec un modèle de générateur. Cela réduirait les instructions fat switch en Terminal.write ce qui est difficile à maintenir pour le moment. Bien sûr, cela a un prix - le générateur est susceptible de fonctionner un peu plus lentement en raison de la surcharge supplémentaire liée à la gestion de l'état de la coroutine.

Pour illustrer cela davantage, la façon dont Terminal.write gère les données est :

for char in data
  switch char
    adjust parser state if needed
    with parser state
      terminal_state_handling
    end
  end
end
trigger event

Ce qui rend cela difficile à maintenir, c'est l'imbrication profonde de la gestion de l'état du terminal dans les états de l'analyseur dans une grande méthode. De plus, il n'est pas garanti qu'à un niveau plus profond, l'état de l'analyseur ne soit pas modifié (cela se produit réellement).

Avec les générateurs, cela peut être réécrit en :

parser:
for char in data
  switch char
    adjust parser state if needed
    yield [parser state, char]
  end
end

terminal:
for [parser state, char] in parser
  with parser state
    terminal_state_handling
  end
end

Cela peut être encore plus simplifié si l'analyseur agrège les codes ANSI en actions de base qu'un terminal doit prendre en charge (API interne) et conduit à une séparation complète de l'analyse du code ANSI et de la gestion du terminal :

parser:
for char in data
  switch char
    adjust parser state if needed
    if action endpoint
        yield [action, aggregated data]
    else
        aggregate char
  end
end

terminal:
for [action, aggregated data] in parser
  call action(aggregated data)
end

Avec un ensemble d'actions bien défini, l'analyseur et le terminal peuvent être développés et testés indépendamment. Étant donné qu'un modèle d'analyseur de code d'échappement complet avec des actions a déjà été spécifié ailleurs (http://vt100.net/emu/dec_ansi_parser), il est assez facile de l'adopter.

Salut @jerch , grâce à vos conseils, je suis prêt à essayer, je vous

@131 Oh ok, ce sera une réécriture majeure de Terminal.write et est quelque peu hors sujet ici, car elle aborde une idée de réécriture spécifique et non le système de construction en particulier. Peut-être qu'un problème de réécriture v2.0 est nécessaire pour suivre toutes les idées restantes - il y en a déjà quelques-unes qui nécessitent plus que de petits correctifs.

Une discussion intéressante a également lieu sur codemirror/CodeMirror#4200.

Oui, je n'utilise pas non plus l'exportation par défaut.
De plus, la modularisation du code est le sujet de tout cela, j'ai également renommé mon PR "remappage ES6" en "modularisation ES6" :sourire:

Nous utilisons le rollup pour la construction et prévoyons d'utiliser buble pour le transpilation ES6.

Salut @adrianheine , j'ai vu que ton RP dans CodeMirror 👍 . Bon travail.

Rollup a incroyablement bien fonctionné, à l'exception de la partie test. Je ne pouvais pas trouver un moyen de le faire fonctionner avec Mocha et je ne voulais pas utiliser différents transpileurs (rollup et babel) pour la sortie et les tests.

Des idées?