Cohérence du Linting

Je jure avoir copié tout le code de lint de discourse-plugin-skeleton dans mon plugin et lorsque j’exécute

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

dans mon répertoire de plugin, j’obtiens quelque chose de différent de lorsque j’exécute

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

dans le répertoire principal de discourse.

Comme on pouvait s’y attendre, je suppose, ce dernier correspond à ce qui se passe lorsque les actions github s’exécutent.

Ce que j’aimerais vraiment, c’est que la Bonne Chose se produise lorsque j’enregistre dans VSCode, ce qui, je suis à peu près sûr, est encore un autre problème.

3 « J'aime »

Oui @cvx / @david

J’ai aussi remarqué cela… le linting dans les plugins est tout du matériel snowflake (matériel spécialisé/unique), nous avons des branches pour l’ancien et le nouveau style de linting dans l’intégration continue (CI) et cela nécessite beaucoup de configuration dans le dépôt.

Je pense qu’un excellent objectif est de le corriger pour que bin/lint fonctionne également pour les plugins et les thèmes. Nous ne l’avons pas encore implémenté, cela ne fonctionne que pour le cœur et les plugins du cœur.

2 « J'aime »

En effet, l’analyse statique (linting) pour les thèmes/plugins est délibérément découplée du cœur. Ils peuvent exécuter différentes versions et configurations des outils d’analyse statique. Ceci est essentiel afin que nous puissions déployer des changements sans casser soudainement l’analyse statique dans tous les dépôts.

Nous pourrions probablement faire fonctionner bin/lint - il devra faire un cd dans le répertoire du plugin/thème, exécuter pnpm i, puis exécuter toutes les commandes d’analyse statique dans le contexte de ce répertoire.

Cela devrait se produire. La plupart des membres de notre équipe utilisent VSCode (ou des dérivés de VSCode), c’est donc pour cela que nous optimisons. Les plugins VSCode pour Eslint et Prettier rechercheront l’installation et la configuration « les plus proches » pour un fichier donné.

Avez-vous exécuté pnpm i dans le répertoire du thème/plugin ? C’est nécessaire pour installer ses dépendances d’analyse statique, afin que VSCode puisse trouver la bonne chose.

1 « J'aime »

Tournures intéressantes

  • lui permettre d’exécuter les règles du cœur en option
  • Lui permettre de reconfigurer la configuration existante pour exécuter les règles du cœur

Quel serait l’avantage de cela ? :sweat_smile:

L’analyse de thèmes/plugins est fondamentalement différente du cœur. Nous avons des règles spécifiques aux thèmes/plugins. Les thèmes ont leurs propres variables globales magiques que ESLint doit connaître (themePrefix/settings)

Nous sommes très prudents quant au maintien de cela, en le documentant dans les dépôts theme/plugin-skeleton, et en déployant les changements méthodiquement via des PR massives.

2 « J'aime »

En tant qu’outil d’auto-amélioration, mais je comprends tout à fait que nous ayons d’autres systèmes

Ah d’accord. Nous avons des scripts pour la mise à jour automatique (à partir du squelette) ici. Les rendre plus conviviaux pour l’exécution sur des thèmes/plugins uniques pourrait être un bon projet.

D’ailleurs, quand je dis qu’ils ont une configuration différente, je ne veux pas dire que nous dupliquons la configuration partout. Nous avons un package de configurations de lint versionné qui inclut des configurations partagées pour prettier, eslint, stylelint et ember-template-lint. La mise à niveau d’un thème/plugin vers les dernières règles est normalement juste une question de mise à jour de la version lint-configs dans le package.json.

1 « J'aime »

Mais je suis presque certain que lorsque je suis l’analyse effectuée dans le plugin, les tests d’analyse échouent dans l’action github.

AHA !!! pnpm i semble être la magie qui me manque. J’ai ajouté le ‘pnpm i’ à mon script qui met à jour discourse core et celui qui fait l’analyse. . .

Alors voici ce que fait mon script :

if [[ "$ARG" == "eslint" ]]
then
  # Voir https://github.com/discourse/.github/blob/main/.github/workflows/discourse-plugin.yml
  if [ -f plugin.rb ]
  then
    echo "Analyse du répertoire courant."
  else
    echo "Pas sur un plugin. Utilisation de $DEFAULT_PLUGIN"
    cd $DEFAULT_PLUGIN
  fi
  echo "ANALYSE DE $(pwd)"
  #cd /home/pfaffman/src/literatecomputing/discourse-display-email
  # pnpm install
  echo "Exécution de `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 n'était pas content -- $exit_code -- tentative de correction"
    pnpm eslint --fix --no-error-on-unmatched-pattern {test,assets,admin/assets}/javascripts
    exit_code="?"
    if [[ $exit_code -ne 0  ]]
    then
      echo "eslint n'était toujours pas content -- $exit_code -- fin du jeu"
      exit
    fi
  fi

  echo ESLINT terminé.

  ## styllint

  echo -n STYLELINT . . .
  pnpm stylelint --allow-empty-input "assets/**/*.scss"
  exit_code="?"
    if [[ $exit_code -ne 0  ]]
    then
      echo "stylelint n'est pas content. Tentative de correction . . . "
    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 n'est toujours pas content. C'est triste. Fin du jeu."
      exit
    fi
  echo "TERMINÉ !"

  ## 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 "exécution de 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 a fait quelque chose!!! -- $?"
      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 "exécution de 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 a fait quelque chose!!! -- $?"
      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 "exécution de 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 a fait quelque chose!!! -- $?"
      pnpm prettier --check --loglevel log "test/**/*.{js,gjs}"
    fi
  fi
  echo "Fini avec 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 "fini avec ember-template-lint --fix --no-error-on-unmatched-pattern assets/javascripts -- avec $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 n'est pas content. Tentative de correction dans 2 secondes . .. "
      sleep 2
      echo "c'est parti !!!"
      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 n'est toujours pas content. C'est triste. Attente pour vous rendre plus triste"
      sleep 15
    fi
  echo fini avec stree

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


Mais j’ai aussi ceci, qui je pense fonctionne presque de la même manière :

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 seule différence maintenant semble être que l’analyse du cœur n’est pas contente de ceci (et je pense que je comprends pourquoi le cœur le trouve et le plugin non, et il n’y a aucun inconvénient à corriger ces dépréciations plus tôt que tard) :


/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 problème (1 erreur, 0 avertissements)

Et si j’utilise bin/lint, alors je n’ai pas à m’inquiéter que quelque chose change dans l’analyse qui nécessite de mettre à jour mon script de 54 lignes. N’est-ce pas ?

Attendez. Les documenter dans les dépôts squelettes ?

J’aimerais bien avoir des conseils sur la façon dont je pourrais déployer les changements méthodiquement, même si je comprends que mon petit ensemble de choses n’est pas vraiment votre problème. . . Ceci n’appartient pas vraiment ici, mais j’ai essayé à quelques reprises de comprendre mass-pr, mais je n’y suis pas encore parvenu. Je copie généralement périodiquement certains fichiers .whatever à partir d’un pull récent du squelette et j’espère le meilleur.

Et il y a 16 de ces scripts. Dois-je surveiller le dépôt et ensuite l’exécuter chaque fois que l’un d’eux est mis à jour ? Et un tas de thèmes semblent ne pas cloner les dépôts squelettes, ils échouent donc à copier les fichiers requis ?

Et plusieurs semblent échouer avec quelque chose comme sed: can’t read s/default.yml/stree-compat.yml/: No such file or directory ? parce qu’ils ne clonent pas les dépôts squelettes ? (Je vais créer un sujet quelque part approprié pour cela quand j’en aurai l’occasion).

bin/lint utilise la configuration de linting du cœur (core) et ne prend donc pas en charge les thèmes ou les plugins. Si vous l’utilisez, vous obtiendrez probablement des échecs dans l’intégration continue (CI) de votre thème/plugin. Par exemple, même de minuscules mises à jour de version de prettier peuvent apporter des changements subtils dans la gestion des espaces.

Oui, c’est essentiellement ce que font les scripts mass-pr :+1:

update-linting.sh est celui que vous voulez. D’autres scripts sont destinés à des déploiements plus spécialisés.

Vous pouvez le faire. Ou vous pouvez simplement le réexécuter de temps en temps, lorsque vous souhaitez mettre à jour la configuration de linting pour votre thème/plugin. Étant donné que la configuration est entièrement autonome, un changement dans le cœur n’affectera jamais le linting dans vos thèmes/plugins - ils sont complètement découplés.

Cool ! Donc, il me suffit de l’exécuter de temps en temps et cela mettra à jour tous les lintings. Les autres servent à faire des choses magiques comme aider à migrer vers le nouvel ember et autres ? Peut-être que je commence à comprendre et je peux faire une liste de dépôts comme dans l’exemple.

Compris. J’étais confus car je n’avais pas exécuté pnpm i, donc le lint du thème/plugin faisait la mauvaise chose et le lint principal était cohérent avec GitHub.

Oui, mais j’adore passer 5 heures à automatiser une tâche que je peux faire à la main en 3 minutes et cela semble être un bon moyen d’y parvenir. :rofl: