Coerenza del Linting

Giuro di aver copiato tutto il codice di lint da discourse-plugin-skeleton al mio plugin e quando eseguo

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

nella directory del mio plugin, ottengo qualcosa di diverso da quando eseguo

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

nella directory principale di discourse.

Prevedibilmente, immagino, quest’ultimo è quello che corrisponde a ciò che accade quando vengono eseguite le azioni di github.

Quello che vorrei davvero è che accadesse la Cosa Giusta quando salvo in VSCode, il che, ne sono abbastanza sicuro, è un altro problema.

3 Mi Piace

@cvx / @david

Ho notato anche questo… il linting nei plugin è tutto materiale “snowflake” (particolare/unico), abbiamo rami per il vecchio e il nuovo stile di linting in CI e richiediamo una serie di configurazioni nel repository.

Penso che un ottimo obiettivo sia sistemare le cose in modo che bin/lint funzioni anche per i plugin e i temi. Non l’abbiamo ancora implementato, funziona solo per il core e i plugin core.

2 Mi Piace

In effetti, il linting per temi/plugin è deliberatamente disaccoppiato dal core. Potrebbero eseguire versioni e configurazioni diverse degli strumenti di linting. Questo è essenziale in modo da poter implementare modifiche senza interrompere improvvisamente il linting in tutti i repository.

Probabilmente potremmo far funzionare bin/lint: dovrà fare cd nella directory del plugin/tema, eseguire pnpm i, e poi eseguire qualsiasi comando di linting nel contesto di quella directory.

Dovrebbe succedere. La maggior parte del nostro team utilizza VSCode (o derivazioni di VSCode), quindi è per questo che ottimizziamo. I plugin di VSCode per Eslint e Prettier cercheranno l’installazione e la configurazione “più vicine” per un dato file.

Hai eseguito pnpm i nella directory del tema/plugin? Questo è necessario per installare le sue dipendenze di linting, in modo che VSCode possa trovare la cosa giusta.

1 Mi Piace

Sviluppi interessanti

  • consentire l’esecuzione facoltativa delle regole di core
  • Consentire la riconfigurazione della configurazione esistente per eseguire le regole di core

Quale sarebbe il vantaggio? :sweat_smile:

L’analisi (linting) di temi/plugin è fondamentalmente diversa da quella del core. Abbiamo regole specifiche per temi/plugin. I temi hanno le proprie variabili globali magiche che ESLint deve conoscere (themePrefix/settings)

Siamo molto attenti a mantenere questo aspetto, documentandolo nei repository theme/plugin-skeleton e implementando le modifiche metodicamente tramite pull request di massa (mass-pr).

2 Mi Piace

Come strumento per l’auto-miglioramento, ma capisco perfettamente che abbiamo altri sistemi

Ah, ok. Abbiamo degli script per l’aggiornamento automatico (dallo scheletro) qui. Renderli più facili da eseguire su singoli temi/plugin potrebbe essere un bel progetto.

A proposito, quando dico che hanno configurazioni diverse, non intendo che stiamo duplicando la configurazione ovunque. Abbiamo un pacchetto di configurazioni di lint versionato che include configurazioni condivise per prettier, eslint, stylelint e ember-template-lint. Aggiornare un tema/plugin alle regole più recenti è normalmente solo una questione di aumentare la versione di lint-configs in package.json.

1 Mi Piace

Ma sono abbastanza sicuro che quando seguo il linting fatto nel plugin, i test di linting falliscono nell’azione di github.

AHA!!! pnpm i sembra essere la magia che mi manca. Ho aggiunto il ‘pnpm i’ al mio script che aggiorna discourse core e quello che fa il linting. . .

Quindi ecco cosa fa il mio script:

if [[ "$ARG" == "eslint" ]]
then
  # Vedi https://github.com/discourse/.github/blob/main/.github/workflows/discourse-plugin.yml
  if [ -f plugin.rb ]
  then
    echo "Linting directory corrente."
  else
    echo "Non su un plugin. Uso $DEFAULT_PLUGIN"
    cd $DEFAULT_PLUGIN
  fi
  echo "LINTING $(pwd)"
  #cd /home/pfaffman/src/literatecomputing/discourse-display-email
  # pnpm install
  echo "Eseguo `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 non era contento -- $exit_code -- provo a sistemare"
    pnpm eslint --fix --no-error-on-unmatched-pattern {test,assets,admin/assets}/javascripts
    exit_code="?"
    if [[ $exit_code -ne 0  ]]
    then
      echo "eslint era ancora scontento -- $exit_code -- gioco finito"
      exit
    fi
  fi

  echo ESLINT fatto.

  ## styllint

  echo -n STYLELINT . . .
  pnpm stylelint --allow-empty-input "assets/**/*.scss"
  exit_code="?"
    if [[ $exit_code -ne 0  ]]
    then
      echo "stylelint è scontento. Provo a sistemare . . . "
    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 è ancora scontento. questo è triste. Gioco finito."
      exit
    fi
  echo "FATTO!"

  ## fine 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 "eseguo 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 ha fatto qualcosa!!! -- $?"
      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 "eseguo 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 ha fatto qualcosa!!! -- $?"
      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 "eseguo 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 ha fatto qualcosa!!! -- $?"
      pnpm prettier --check --loglevel log "test/**/*.{js,gjs}"
    fi
  fi
  echo "Fatto 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 "fatto 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 è scontento. Provo a sistemare tra 2 secondi . .. "
      sleep 2
      echo "ecco qui!!!"
      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 è ancora scontento. questo è triste. Aspetto per renderti più triste"
      sleep 15
    fi
  echo fatto con stree

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


Ma ho anche questo, che penso funzioni quasi allo stesso modo:

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

L’unica differenza ora sembra essere che il linting del core non è contento di questo (e penso di capire perché il core lo trovi e il plugin no, e non c’è svantaggio nel correggere quelle deprecazioni prima piuttosto che dopo):


/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 errore, 0 avvisi)

E se uso bin/lint allora non devo preoccuparmi che qualcosa cambi nel linting che richieda l’aggiornamento del mio script di 54 righe. Giusto?

Aspetta. Documentandoli dove negli skeleton repository?

Mi piacerebbe avere qualche indicazione su come potrei implementare le modifiche metodicamente, anche se capisco che il mio piccolo insieme di cose non è davvero un vostro problema. . . Questo non appartiene davvero qui, ma ho provato un paio di volte a capire mass-pr, ma non ci sono ancora riuscito. Di solito copio periodicamente alcuni file .whatever da un pull recente dello skeleton e spero per il meglio.

E ci sono 16 di quegli script. Devo monitorare il repository ed eseguirlo ogni volta che uno di essi viene aggiornato? E parecchi temi non clonano gli skeleton quindi falliscono nel copiare i file necessari?

E diversi falliscono con qualcosa come sed: can’t read s/default.yml/stree-compat.yml/: No such file or directory ? perché non clonano gli skeleton repository? (Inizierò un argomento da qualche parte appropriato per questo quando ne avrò l’occasione).

bin/lint utilizza la configurazione di linting del core e quindi non supporta temi o plugin. Se lo usi, probabilmente otterrai fallimenti nel CI del tuo tema/plugin. Ad esempio, anche piccoli aggiornamenti di versione a prettier possono apportare sottili modifiche alla gestione degli spazi bianchi.

Sì, questo è essenzialmente ciò che fanno gli script mass-pr :+1:

update-linting.sh è quello che vuoi. Altri script sono per rollout più specializzati.

Puoi farlo. Oppure puoi semplicemente rieseguirlo ogni tanto, quando vuoi aggiornare la configurazione di linting per il tuo tema/plugin. Poiché la configurazione è completamente autonoma, una modifica nel core non influenzerà mai il linting nei tuoi temi/plugin: sono completamente disaccoppiati.

Fantastico! Quindi devo eseguire solo quello ogni tanto e aggiornerà tutti i linting. Gli altri servono per fare cose magiche come aiutare la migrazione al nuovo ember e cose del genere? Forse sto iniziando a capire e posso creare un elenco di repository come nell’esempio.

Capito. Ero confuso perché non avevo eseguito pnpm i, quindi il lint del tema/plugin stava facendo la cosa sbagliata e il lint principale era coerente con GitHub.

Sì, ma adoro passare 5 ore ad automatizzare un’attività che posso fare a mano in 3 minuti e questo sembra un buon modo per farlo. :rofl: