Pegjs: Explorer la suppression de la prise en charge d'Internet Explorer
Je pense qu'avant de publier la 0.12, je devrais abandonner complètement le support d'Internet Explorer (à la fois de la bibliothèque et de l'éditeur en ligne). Il y a plusieurs raisons à cela;
- Plus d'heures supplémentaires de développement de logiciels semblent ne pas fonctionner avec (dans cette cause, les modules NPM)
- Google Analytics montre une énorme baisse du nombre d'utilisateurs d'IE11 au cours des 2 dernières années
- C'est devenu pénible d'essayer d'éviter d'utiliser les composants intégrés ECMAScript non pris en charge par IE11
- Je trouve ça douloureux en général maintenant 😅
Dans les mois à venir, je prévois d'ajouter des modifications qui prennent en charge la compatibilité permanente (en utilisant les fonctions intégrées ES2015+ via des polyfills) ; après cela, je déciderai si cela vaut la peine ou non d'abandonner totalement le support pour IE ; En attendant, n'hésitez pas à décourager (ou encourager) ce changement.
futagoza
Tous les 2 commentaires
Non.
IE est le troisième navigateur le plus répandu au monde, et il n'y a aucun problème pour Peg sous IE. Il y a des problèmes majeurs pour PEG qui n'ont rien à voir avec IE que nous attendons depuis trois ans que vous les résolviez.
Il n'y a pas besoin ou appel de polyfills dans PEG. Rien dans PEG ne veut ou n'en a besoin. Vous allez multiplier par 10 la taille de l'analyseur sans raison, pour résoudre des problèmes qui n'existent pas.
Veuillez envisager de confier PEG à une personne expérimentée pour relancer les versions. Vous n'avez rien publié, et vous avez changé la forme de la bibliothèque pour qu'aucun des anciens contributeurs ne soit même plus capable de réparer de petites choses. Vous travaillez sur un analyseur différent dans une langue différente avec un AST différent qu'aucun de nous ne pourra utiliser.
Si vous voulez écrire un nouveau moteur PEG, très bien, allez-y.
Ne tuez pas celui-ci. Récupérons notre logiciel maintenant
.
Plus d'heures supplémentaires de développement de logiciels semblent ne pas fonctionner avec (dans cette cause, les modules NPM)
Respectueusement, il n'y a aucune surcharge d'IE.
StoneCypher
le 2 févr. 2020
C'est devenu pénible d'essayer d'éviter d'utiliser les composants intégrés ECMAScript non pris en charge par IE11
Vous ne devriez pas faire ça. Vous devriez accepter les correctifs de 2016 et 2017 qui nous permettent de les utiliser directement.
Un analyseur ne devrait pas essayer d'utiliser des shims.
Un analyseur ne devrait pas essayer de dicter ce qui entre en fonction de la machine extérieure.
Un analyseur ne doit pas interagir avec NPM.
Un analyseur ne devrait pas vous obliger à installer des gestionnaires de packages.
Un analyseur au niveau des caractères ne devrait pas avoir besoin de la prise en charge d'un navigateur pour effectuer l'analyse.
Vous ne devriez pas utiliser d'outils extérieurs à un parseur pour faire de l'analyse .
Un analyseur sans bibliothèque ne devrait pas être bloqué sur l'abandon des utilisateurs actifs sur le support de la bibliothèque pour effectuer l'analyse.
Il y a une raison pour laquelle aucun des autres analyseurs ne fonctionne de cette façon.
S'il vous plaît, laissez quelqu'un ramener cela à un analyseur sain, normal et atypique maintenant. Je serais heureux de vous aider. Je peux vous offrir un support es6 et dactylographié en moins de 30 jours sans aucun changement majeur, en 0.10, de la même manière que j'ai dit que je pouvais le faire en 2018. Nous n'avons pas besoin de changements architecturaux majeurs, cassant les remplacements d'AST, pour abandonner le support du navigateur, une programmation changement de langue, un nouvel analyseur à partir de zéro, ou tout cela.
Nous avons besoin d'un mainteneur qui soit prêt à accepter de petits correctifs, à avoir de petites versions de taille gérable et qui soit prêt à maintenir la bibliothèque dans un état sain à tout moment.
Personne n'a pu cotiser depuis 2017.
Il est temps pour vous de laisser quelqu'un d'autre vous aider.
StoneCypher
le 2 févr. 2020
Questions connexes
doersino
·
15Commentaires
gatsbyz
·
3Commentaires
futagoza
·
13Commentaires
dmajda
·
15Commentaires
mikeaustin
·
7Commentaires
Commentaire le plus utile
Vous ne devriez pas faire ça. Vous devriez accepter les correctifs de 2016 et 2017 qui nous permettent de les utiliser directement.
Un analyseur ne devrait pas essayer d'utiliser des shims.
Un analyseur ne devrait pas essayer de dicter ce qui entre en fonction de la machine extérieure.
Un analyseur ne doit pas interagir avec NPM.
Un analyseur ne devrait pas vous obliger à installer des gestionnaires de packages.
Un analyseur au niveau des caractères ne devrait pas avoir besoin de la prise en charge d'un navigateur pour effectuer l'analyse.
Vous ne devriez pas utiliser d'outils extérieurs à un parseur pour faire de l'analyse .
Un analyseur sans bibliothèque ne devrait pas être bloqué sur l'abandon des utilisateurs actifs sur le support de la bibliothèque pour effectuer l'analyse.
Il y a une raison pour laquelle aucun des autres analyseurs ne fonctionne de cette façon.
S'il vous plaît, laissez quelqu'un ramener cela à un analyseur sain, normal et atypique maintenant. Je serais heureux de vous aider. Je peux vous offrir un support es6 et dactylographié en moins de 30 jours sans aucun changement majeur, en 0.10, de la même manière que j'ai dit que je pouvais le faire en 2018. Nous n'avons pas besoin de changements architecturaux majeurs, cassant les remplacements d'AST, pour abandonner le support du navigateur, une programmation changement de langue, un nouvel analyseur à partir de zéro, ou tout cela.
Nous avons besoin d'un mainteneur qui soit prêt à accepter de petits correctifs, à avoir de petites versions de taille gérable et qui soit prêt à maintenir la bibliothèque dans un état sain à tout moment.
Personne n'a pu cotiser depuis 2017.
Il est temps pour vous de laisser quelqu'un d'autre vous aider.