Jshint: La sangría de pestañas rompe varias reglas

¡Gracias por el informe! El problema surge de la línea 1610 de lex.js :

this.input = this.input.replace(/\t/g, state.tab);

Esto parece bastante fundamental para la cantidad de reglas de pelusa relacionadas con el estilo que se implementan. Han quedado en desuso desde hace algún tiempo, pero aún no estamos listos para pasar a una nueva versión principal. Entonces, mientras tanto, tendremos que diseñar una solución que conserve ese comportamiento.

Mi pensamiento inicial es rastrear este "desplazamiento efectivo" como una nueva propiedad del objeto token llamado column . Esto se puede usar para esas advertencias relacionadas con el estilo. Luego, el atributo character podría volver a implementarse para describir el desplazamiento del carácter "verdadero", donde cada punto de código (tabulador o de otro tipo) incrementa el conteo en exactamente 1. Este valor se usaría para emitir advertencias. Los complementos de Reporter tendrían el control de cómo representan el carácter de tabulación y podrían interpretar el número de "columna" informado en consecuencia.

¿Te suena bien, @Arcanemagus?

Eso suena perfecto para mí, al menos en la superficie sin un conocimiento real de las partes internas de JSHint 😛. Idealmente, solo necesito algún método para obtener el verdadero recuento de columnas (donde cada punto de código cuenta como una columna).

Esto se ocultó durante un tiempo debido a que esta advertencia se ignoró esencialmente debido a una solución para un error antiguo del analizador con un error semicomún. Cuando volví a implementar la advertencia a los usuarios de una manera mucho más agradable, los _oculté_ accidentalmente, y recientemente lo arreglé para que esto volviera a ser visible.

Parece que W030 , W033 y W009 también se ven afectados. Según su descripción, asumo que _todas_ las reglas se ven afectadas.

También estoy experimentando este problema y puedo replicar tanto los errores como las advertencias. El tipo de regla/error no parece importar.

Aquí hay un ejemplo de jshint que intenta advertirme que mi '==' debería ser '==='. Tenga en cuenta la ubicación errónea del subrayado naranja:

Esperemos que esto confirme sus pensamientos sobre el tema.

Tengo algo de tiempo para investigar un poco hoy, y creo que establecer la opción indent en 1 producirá los resultados deseados.

@Arcanemagus ¿Puede anular el valor de la opción indent para sus consumidores? Si esto es posible, prefiero hacerlo, ya que no estoy seguro de cómo cambiar el valor predeterminado en JSHint podría afectar a sus consumidores.

Hmmm, actualmente este proyecto usa la interfaz CLI que parece. Es posible reescribirlo para usar la API de Node.js que lo haría posible.

• ¿Forzar el indent cambiaría los resultados que ven los consumidores? El objetivo de ese paquete es estar lo más cerca posible de ejecutar jshint por sí mismos, pero obteniendo los resultados integrados en el editor.
• ¿La API JSHint tiene un método oculto para obtener la configuración de un archivo, o sería necesario implementarlo? La documentación actual no muestra tal función.

¿Qué tal agregar un argumento de línea de comando que permita anular los valores de la configuración?
Algo así es común en herramientas como -g en nginx, -o en ssh, -c en git y muchas más, supongo.

$ jshint -o "indent = 1" -o "-W034 = true" -o "globals.require = false" -o "globals.$ = null"

¿Alguien sabe en qué versión se introdujo esto? 2.9.5?

Al menos entonces podríamos bajar de categoría por el momento como temporal. reparar.

@jaredatch De vuelta en https://github.com/AtomLinter/linter-jshint/pull/386 (lanzado en v3.1.0 de linter-jshint ) se eliminaron todas las soluciones para el informe de puntos de error de JSHint. El objetivo de esa verificación es encontrar errores como este donde el linter informa puntos no válidos para que se pueda informar y corregir para _todos_ que usan el linter. (Después de todo, si no puede confiar en que el linter le proporcione datos precisos, ¿por qué usarlo?)

Puede haber un "punto ideal" antes de que se introdujera este error de pestaña y después de los principales errores del analizador que causaron que se implementaran esas soluciones en primer lugar.

@Arcanemagus gotcha, realmente aprecio la idea. Sigan con el gran trabajo 👍

Si tiene una idea de mensaje mejor / más útil sobre cómo linter-jshint informa estos puntos no válidos, no dude en presentar un problema / enviar un PR allí 😉.

POR FAVOR, TODAS TUS SOLUCIONES APESTAN HE PASADO LAS ÚLTIMAS 5 HORAS TRATANDO DE LIBERAR UN ARCHIVO JAVASCRIPT ES EL 2017 POR QUÉ ESTOY TENIENDO ESTE PROBLEMA ÁTOMO ES LA MIERDA DE MI VIDA ARREGLATE TU MISMO ESTÚPIDO

Y QUIÉN MIERDA NO UTILIZA PESTAÑAS PARA INGRESAR LITERALMENTE WTF ¿POR QUÉ LLEVARÍAS UN PAQUETE ROTO A LOS MILLONES QUE LINT JS???????

¿Quién no usa los puntos literalmente, por qué lanzas este inglés roto a los millones que es el inglés?

Oh. Y los caracteres en mayúscula van al comienzo de una oración. No en todas partes.

/Troll (sry, no pude evitarlo)

Bueno, supongo que la solución será desactivar esto por el momento...
¿Quién necesita linters de todos modos?

@jugglinmike ¿Puede responder las preguntas en https://github.com/jshint/jshint/issues/3151#issuecomment -312512856?

Tengo 20 problemas únicos abiertos para diferentes casos en los que esto se activa, ya que parece que arreglar esto aquí llevará un tiempo. Me gustaría seguir adelante con la solución, asumiendo que no cambiará los resultados para los usuarios.

Este problema se me escapó del radar; Lo siento, @Arcanemagus. Desafortunadamente, no creo que pueda darle a esto la atención que merece hasta este fin de semana. ¿Funcionará para ti?

@jugglinmike Por supuesto 😉

Puse algunas comprobaciones para los problemas existentes, por lo que en su mayor parte las personas están siendo filtradas a los problemas ya abiertos que apuntan aquí.

@cobexer Me gusta esa idea porque además de darnos un camino a seguir,
podría ser útil para la gente en otros contextos. Dicho esto, que yo sepa, hay
nunca ha habido una solicitud de ese tipo de funcionalidad, y soy reacio a
comprometerse con cualquier función nueva solo porque parece agradable. Y hay razón para
desalentar esa característica en particular: entre archivos "rc", en línea
configuración y la API de Node.js, los usuarios ya se tropiezan cuando quieren
para entender por qué una opción dada está habilitada. Agregar otro vector para la configuración
la administración tendería a exacerbar este problema.

Creo que la solución más viable aquí se basa en mi anteriorpropuesta
Sin embargo, tenemos que considerar la propiedad character como una API pública: Atom
Después de todo, el complemento del editor se basa en él. Así que en lugar de modificar eso
propiedad y definiendo una nueva que tenga la semántica de la actual, creo
necesitamos dejar character tal cual y exponer los datos solicitados en un nuevo
nombre de la propiedad.

Empecé a trabajar en la nueva función este fin de semana. Quiero evitar regresiones en
todos los costos, por lo que necesitamos extender las pruebas del proyecto para afirmar consistentemente el
número de carácter esperado. Cuando comencé a hacer esto, encontré deficiencias en el
conjunto de pruebas que deben abordarse primero. gh-3174 es el primer paso hacia
ese objetivo

Todo esto es para decir: parece que esto puede llevar algún tiempo. @Arcanemagus lo sé
usted está soportando la peor parte de este error, y le agradezco que lo tome como una
oportunidad de ver JSHint mejorado. También me gusta que te interese
evitando cualquier solución que no sea transparente para sus usuarios. en el corto
término, ¿ha tenido suerte recomendando a los usuarios que establezcan la opción indent en 1 ?
No es lo ideal, pero hacerlo debería resolver su problema a corto plazo de una manera
eso seguirá funcionando incluso después de que lo solucionemos.

@Arcanemagus Sé que estás soportando la peor parte de este error, y agradezco que lo tomes como un
oportunidad de ver JSHint mejorado.

La razón principal por la que agregué el cheque a la biblioteca genérica utilizada por la mayoría de los proveedores de Linter para Atom es para que los errores como este puedan detectarse en los linters de origen y se informen/arreglen 😉. En realidad, esto se habría detectado antes, pero hubo un control en linter-jshint que básicamente ocultó todos los errores de puntos no válidos de _way_ cuando el analizador falló por completo en la mayoría de los documentos y no teníamos una buena manera de informarlo. a los usuarios o de la eliminación de duplicados de informes de problemas. Ahora que se han resuelto, eliminé ese cheque y aquí estamos 😛.

También me gusta que te interese evitar cualquier solución que no sea transparente para tus usuarios.

En realidad, una solución transparente para este problema en particular estaría bien, simplemente no sé si forzar la configuración de indent a 1 cambiaría los resultados que están viendo en comparación con lo que obtendrían de ejecutando jshint ellos mismos.

A corto plazo, ¿ha tenido suerte recomendando a los usuarios que establezcan la opción de sangría en 1?

Esa es... una idea excelente que en realidad no había pensado en publicar en esos números. ¡Me aseguraré de mencionarlo en los temas más comentados!

Oh, sí, establecer la propiedad 'sangría' en 1 en .jshintrc es una excelente solución. Ojalá supiera eso antes. Ya tengo un .jshintrc porque jshint no tiene el valor predeterminado es6, por lo que es fácil de agregar. 👍

¡Me alegra escucharlo, @tustin2121!

Actualización: todavía estoy trabajando para apuntalar el conjunto de pruebas JSHint para evitar regresiones. El último en ese esfuerzo es gh-3176.

¿Alguna actualización sobre este tema?

Parece que ahora tenemos al menos 40 reglas diferentes afectadas por este error 😛.

Cualquier actualización sobre esto, hace algunos meses que tengo estos errores, lo que me vuelve loco :)

¡Hola @xcrap! Acabo de revisar el hilo de comentarios, y no parece que nadie haya publicado ninguna actualización. La buena noticia es que JSHint es un proyecto de código abierto, por lo que puede ayudar a solucionar el problema si le causa estrés. ¿Te gustaría echar una mano? Estaré encantado de aconsejarle.

@jugglinmike ¡Ojalá! Siempre lo intento en proyectos pequeños, pero mis habilidades js son súper básicas y limitadas :)

Coloqué una recompensa de $50 por este error, otros pueden contribuir a aumentar la recompensa a través de este enlace: https://www.bountysource.com/issues/46533252-tab-indentation-breaks-multiple-rules

Tirar de la bifurcación de @tzvipm localmente y reconstruir jshint funcionó para solucionar el problema si alguien más se topa con esto:

git clone https://github.com/tzvipm/jshint
git remote add upstream [email protected]:jshint/jshint.git
git fetch upstream
git stash
git merge upstream/master
git mergetool --tool=opendiff
npm run build