Consistencia de Linting

Juro que he copiado toda la configuración de lint de discourse-plugin-skeleton a mi plugin y cuando ejecuto

pnpm prettier  --write "assets/**/*.{scss,js,gjs,hbs}"

en mi directorio de plugin, obtengo algo diferente a cuando ejecuto

./bin/lint  --fix plugins/discourse-pfaffmanager/assets/**/*.{scss,js,gjs,hbs}

en el directorio principal de Discourse.

Previsiblemente, supongo, el segundo es el que coincide con lo que sucede cuando se ejecutan las acciones de GitHub.

Lo que realmente me gustaría es que sucediera lo Correcto cuando guardo en VSCode, lo cual, estoy bastante seguro, es otro problema.

3 Me gusta

Sí, @cvx / @david

Yo también noté esto… el linting en los plugins es todo material snowflake (especial/único), tenemos ramas para el estilo antiguo vs. el nuevo de linting en CI y se requiere una gran configuración en el repositorio.

Creo que un gran objetivo es arreglarlo para que bin/lint funcione también para plugins y temas. Aún no lo hemos implementado, solo funciona para el núcleo y los plugins del núcleo.

2 Me gusta

De hecho, el linting para temas/plugins está deliberadamente desacoplado del núcleo. Podrían ejecutar diferentes versiones y configuraciones de las herramientas de linting. Esto es esencial para que podamos implementar cambios sin romper repentinamente el linting en todos los repositorios.

Probablemente podríamos hacer que bin/lint funcione; necesitará hacer cd al directorio del plugin/tema, ejecutar pnpm i, y luego ejecutar cualquier comando de linting en el contexto de ese directorio.

Debería hacerlo. La mayoría de nuestro equipo usa VSCode (o derivaciones de VSCode), así que para eso optimizamos. Los plugins de Eslint y Prettier para VSCode buscarán la instalación y configuración ‘más cercana’ para un archivo dado.

¿Has ejecutado pnpm i en el directorio del tema/plugin? Eso es necesario para instalar sus dependencias de linting, para que VSCode pueda encontrar lo correcto.

1 me gusta

Giros interesantes

  • Permitir que se ejecuten opcionalmente las reglas del núcleo
  • Permitir reconfigurar la configuración existente para ejecutar las reglas del núcleo

¿Cuál sería el beneficio de eso? :sweat_smile:

La comprobación de temas/plugins es fundamentalmente diferente del núcleo. Tenemos reglas específicas para temas/plugins. Los temas tienen sus propios globales mágicos que ESLint necesita conocer (themePrefix/settings)

Somos muy cuidadosos al mantener esto, documentándolo en los repositorios theme/plugin-skeleton y aplicando los cambios metódicamente a través de PR masivos.

2 Me gusta

Como herramienta para la auto-mejora, pero entiendo totalmente que tenemos otros sistemas

Ah, de acuerdo. Tenemos scripts para la actualización automática (desde el esqueleto) aquí. Hacerlos más amigables para ejecutarse en temas/plugins individuales podría ser un buen proyecto.

Por cierto, cuando digo que tienen configuraciones diferentes, no quiero decir que estemos duplicando la configuración en todas partes. Tenemos un paquete versionado de configuraciones de lint que incluye configuraciones compartidas para prettier, eslint, stylelint y ember-template-lint. Actualizar un tema/plugin a las últimas reglas es normalmente solo cuestión de aumentar la versión de lint-configs en el package.json.

1 me gusta

Pero estoy bastante seguro de que cuando sigo el linting realizado en el plugin, las pruebas de linting fallan en la acción de github.

¡¡¡AJA!!! pnpm i parece ser la magia que me falta. He añadido el ‘pnpm i’ a mi script que actualiza el núcleo de discourse y al que realiza el linting. . .

Así que ahora esto es lo que hace mi script:

if [[ "$ARG" == "eslint" ]]
then
  # Ver https://github.com/discourse/.github/blob/main/.github/workflows/discourse-plugin.yml
  if [ -f plugin.rb ]
  then
    echo "Linting directorio actual."
  else
    echo "No es un plugin. Usando $DEFAULT_PLUGIN"
    cd $DEFAULT_PLUGIN
  fi
  echo "LINTING $(pwd)"
  #cd /home/pfaffman/src/literatecomputing/discourse-display-email
  # pnpm install
  echo "Haciendo `pnpm i`"
  pnpm -i

  echo -n ESLINT . . .
  pnpm eslint --no-error-on-unmatched-pattern {test,assets,admin/assets}/javascripts
  exit_code="?"
  if [[ $exit_code -ne 0  ]]
  then
    echo "eslint no estaba contento -- $exit_code -- intentando arreglar"
    pnpm eslint --fix --no-error-on-unmatched-pattern {test,assets,admin/assets}/javascripts
    exit_code="?"
    if [[ $exit_code -ne 0  ]]
    then
      echo "eslint seguía sin estar contento -- $exit_code -- se acabó el juego"
      exit
    fi
  fi

  echo ESLINT hecho.

  ## styllint

  echo -n STYLELINT . . .
  pnpm stylelint --allow-empty-input "assets/**/*.scss"
  exit_code="?"
    if [[ $exit_code -ne 0  ]]
    then
      echo "stylelint no está contento. Intentando arreglar . . . "
    fi
  pnpm stylelint --fix --allow-empty-input "assets/**/*.scss"
  pnpm stylelint --allow-empty-input "assets/**/*.scss"
  exit_code="?"
    if [[ $exit_code -ne 0  ]]
    then
      echo "stylelint sigue sin estar contento. esto es triste. Se acabó el juego."
      exit
    fi
  echo "¡HECHO!"

  ## fin stylelint

  ## PRETTIER

  echo -n "Prettier . . . "
  if [ -n "$(find assets -type f \( -name "*.scss" -o -name "*.js" -o -name "*.gjs" -o -name "*.hbs" \) 2>/dev/null)" ]; then
    #pnpm prettier --write                  'assets/**/*.{scss,js,gjs,es6,hbs}'
    # echo "haciendo pnpm prettier --write --log-level warn assets/**/*.{scss,js,gjs,es6,hbs}"
    pnpm prettier --write --log-level error "assets/**/*.{scss,js,gjs,hbs}"
    if [[ $? -ne 0  ]]
    then
      echo "prettier assets hizo algo!!! -- $?"
      sleep 5
    fi
  fi
  if [ -n "$(find admin/assets -type f \( -name "*.scss" -o -name "*.js" -o -name "*.gjs" -o -name "*.hbs" \) 2>/dev/null)" ]; then
    #pnpm prettier --write                  'assets/**/*.{scss,js,gjs,es6,hbs}'
    # echo "haciendo pnpm prettier --write --log-level warn admin/assets/**/*.{scss,js,gjs,hbs}"
    pnpm prettier --write --log-level log "assets/**/*.{scss,js,gjs,es6,hbs}"
    if [[ $? -ne 0  ]]
    then
      echo "prettier admin/assets hizo algo!!! -- $?"
      pnpm prettier --check --log-level log "assets/**/*.{scss,js,gjs,es6,hbs}"
    fi
  fi
  if [ -n "$(find test -type f \( -name "*.js" -o -name "*.gjs" \) 2>/dev/null)" ]; then
    #pnpm prettier --write                  'assets/**/*.{scss,js,gjs,es6,hbs}'
    # echo "haciendo pnpm prettier --write --log-level warn assets/**/*.{scss,js,gjs,es6,hbs}"
    pnpm prettier --write --log-level warn "test/**/*.{js,gjs}"
    if [[ $? -ne 0  ]]
    then
      echo "prettier test hizo algo!!! -- $?"
      pnpm prettier --check --loglevel log "test/**/*.{js,gjs}"
    fi
  fi
  echo "Fin con prettier"

  echo "ember-template-lint"
  pnpm ember-template-lint --fix --no-error-on-unmatched-pattern assets/javascripts admin/assets/javascripts
  exit_code="?"
    if [[ $exit_code -ne 0  ]]
    then
      echo "fin con ember-template-lint --fix --no-error-on-unmatched-pattern assets/javascripts -- con $exit_code"
      echo sleep 5
      sleep 5
    fi
  #bundle exec stree write Gemfile $(git ls-files '*.rb') $(git ls-files '*.rake') $(git ls-files '*.thor')
  bundle exec stree check Gemfile $(git ls-files '*.rb') $(git ls-files '*.rake') $(git ls-files '*.thor')
  exit_code="?"
    if [[ $exit_code -ne 0  ]]
    then
      echo "stree no está contento. Intentando arreglar en 2 segundos . .. "
      sleep 2
      echo "¡aquí vamos!!!"
      bundle exec stree write Gemfile $(git ls-files '*.rb') $(git ls-files '*.rake') $(git ls-files '*.thor')
    fi
  bundle exec stree check Gemfile $(git ls-files '*.rb') $(git ls-files '*.rake') $(git ls-files '*.thor')
  exit_code="?"
    if [[ $exit_code -ne 0  ]]
    then
      echo "stree sigue sin estar contento. esto es triste. Esperando para hacerte más triste"
      sleep 15
    fi
  echo fin con stree

  echo "rubocop!"
  bundle exec rubocop -A $(find . -name "*.rb"|grep -v gems)
  exit_code="?"
  if [[ $exit_code -ne 0  ]]
  then
    echo "fin con rubocop -- $exit_code"
    sleep 15
  fi
  exit
fi


Pero también tengo esto, que creo que funciona casi igual:

if [[ "$ARG" ==  "lint" ]]
then
  cd ~/src/discourse-repos/discourse
  find plugins/discourse-pfaffmanager/assets -type f \( -name "*.scss" -o -name "*.js" -o -name "*.gjs" -o -name "*.hbs" -o -name "*.rb" \) -exec ./bin/lint --fix {} +
  cd -
fi

La única diferencia ahora parece ser que el linting del núcleo no está contento con esto (y creo que entiendo por qué el núcleo lo encuentra y el plugin no, y no hay desventaja en arreglar esas deprecaciones antes que después):


/home/pfaffman/src/discourse-repos/discourse/plugins/discourse-pfaffmanager/assets/javascripts/discourse/components/modal/really-delete.gjs
  2:8  error  Use Glimmer components(@glimmer/component) instead of classic components(@ember/component)  ember/no-classic-components

✖ 1 problema (1 error, 0 advertencias)

Y si uso bin/lint entonces no tengo que preocuparme de que algo cambie en el linting que requiera actualizar mi script de 54 líneas. ¿Verdad?

Espera. ¿Documentándolos dónde en los repositorios skeleton?

Me encantaría recibir orientación sobre cómo podría desplegar cambios metódicamente, aunque entiendo que mi pequeño conjunto de cosas no es realmente vuestro problema. . . Esto en realidad no pertenece aquí, pero he intentado un par de veces entender mass-pr, pero todavía no he tenido éxito. Normalmente copio periódicamente algunos archivos .whatever de un pull reciente del skeleton y espero lo mejor.

¿Y hay 16 de esos scripts? ¿Debo vigilar el repositorio y luego ejecutarlo cada vez que se actualice alguno de ellos? ¿Y varios temas parecen no clonar los repositorios skeleton, por lo que fallan al copiar los archivos necesarios?

¿Y varios fallan con algo como sed: can’t read s/default.yml/stree-compat.yml/: No such file or directory? ¿porque no clonan los repositorios skeleton? (Iniciar un tema en algún lugar apropiado para eso cuando tenga la oportunidad).

bin/lint usa la configuración de linting del núcleo y, por lo tanto, no admite temas ni complementos. Si lo usas, es probable que obtengas fallos en la integración continua (CI) de tu tema/complemento. Por ejemplo, incluso las pequeñas actualizaciones de versión de Prettier pueden realizar cambios sutiles en el manejo del espacio en blanco.

Sí, eso es esencialmente lo que hacen los scripts de mass-pr :+1:

update-linting.sh es el que quieres. Otros scripts son para implementaciones más especializadas.

Puedes hacerlo. O puedes simplemente volver a ejecutarlo de vez en cuando, cuando quieras actualizar la configuración de linting para tu tema/complemento. Dado que la configuración está totalmente autocontenida, un cambio en el núcleo nunca afectará al linting en tus temas/complemento; están completamente desacoplados.

¡Genial! Así que solo necesito ejecutar ese de vez en cuando y actualizará todos los lintings. ¿Los otros son para hacer cosas mágicas como ayudar a migrar a un nuevo ember y demás? Quizás estoy empezando a entender y puedo hacer una lista de repositorios como en el ejemplo.

Entendido. Estaba confundido porque no había ejecutado pnpm i, por lo que el lint del tema/plugin estaba haciendo lo incorrecto y el lint principal era consistente con github.

Sí, pero me encanta pasar 5 horas automatizando una tarea que puedo hacer a mano en 3 minutos y esta parece una buena manera de hacerlo. :rofl: