Consistência de Linting

Juro que copiei todo o conteúdo de lint do discourse-plugin-skeleton para o meu plugin e, quando executo

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

no diretório do meu plugin, obtenho algo diferente do que acontece quando executo

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

no diretório principal do discourse.

Previsivelmente, eu acho, o último é o que corresponde ao que acontece quando as ações do github são executadas.

O que eu realmente gostaria é que a Coisa Certa acontecesse quando eu salvo no VSCode, o que, tenho quase certeza, é outro problema.

3 curtidas

Sim @cvx / @david

Eu também notei isso… a verificação de estilo (linting) nos plugins é todo material snowflake (complexo/único), temos branches para o estilo antigo versus o novo de verificação de estilo no CI e exigimos uma série de configurações no repositório.

Acho que um ótimo objetivo é consertar isso para que bin/lint funcione também para plugins e temas. Ainda não implementamos isso, só funciona para o core e plugins do core.

2 curtidas

De fato, a verificação de estilo (linting) para temas/plugins é deliberadamente desacoplada do núcleo. Eles podem executar versões e configurações diferentes das ferramentas de verificação de estilo. Isso é essencial para que possamos implementar mudanças sem quebrar subitamente a verificação de estilo em todos os repositórios.

Provavelmente poderíamos fazer o bin/lint funcionar - ele precisará mudar de diretório (cd) para o diretório do plugin/tema, executar pnpm i e, em seguida, rodar quaisquer comandos de verificação de estilo no contexto desse diretório.

Deveria acontecer. A maioria da nossa equipe usa VSCode (ou derivações do VSCode), então é para isso que otimizamos. Os plugins do Eslint e do Prettier para VSCode procurarão a instalação e a configuração ‘mais próximas’ para um determinado arquivo.

Você executou pnpm i no diretório do tema/plugin? Isso é necessário para instalar suas dependências de verificação de estilo, para que o VSCode possa encontrar a coisa certa.

1 curtida

Reviravoltas interessantes

  • permitir que execute opcionalmente as regras do core
  • Permitir que reconfigure a configuração existente para executar as regras do core

Qual seria o benefício disso? :sweat_smile:

A verificação de temas/plugins é fundamentalmente diferente do núcleo. Temos regras específicas para temas/plugins. Os temas têm suas próprias variáveis globais mágicas que o ESLint precisa conhecer (themePrefix/settings)

Somos muito cuidadosos ao manter isso, documentando-o nos repositórios theme/plugin-skeleton e implementando mudanças metodicamente via PRs em massa.

2 curtidas

Como uma ferramenta para auto-atualização, mas eu entendo totalmente que temos outros sistemas

Ah, ok. Temos scripts para atualização automática (a partir do esqueleto) aqui. Torná-los mais amigáveis para rodar em temas/plugins únicos poderia ser um bom projeto.

A propósito, quando digo que eles têm configurações diferentes, não quero dizer que estamos duplicando a configuração em todos os lugares. Temos um pacote versionado de configs de lint que inclui configurações compartilhadas para prettier, eslint, stylelint e ember-template-lint. Atualizar um tema/plugin para as regras mais recentes é normalmente apenas uma questão de aumentar a versão do lint-configs no package.json.

1 curtida

Mas tenho quase certeza de que, quando sigo a verificação de sintaxe feita no plugin, os testes de verificação de sintaxe falham na ação do github.

AHA!!! pnpm i parece ser a mágica que estou perdendo. Adicionei o ‘pnpm i’ ao meu script que atualiza o discourse core e ao que faz a verificação de sintaxe. . .

Então, veja o que meu script faz agora:

if [[ \"$ARG\" == \"eslint\" ]]
then
  # Veja https://github.com/discourse/.github/blob/main/.github/workflows/discourse-plugin.yml
  if [ -f plugin.rb ]
  then
    echo \"Verificando sintaxe no diretório atual.\"
  else
    echo \"Não está em um plugin. Usando $DEFAULT_PLUGIN\"
    cd $DEFAULT_PLUGIN
  fi
  echo \"VERIFICANDO SINTAXE $(pwd)\"
  #cd /home/pfaffman/src/literatecomputing/discourse-display-email
  # pnpm install
  echo \"Fazendo `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ão ficou feliz -- $exit_code -- tentando corrigir\"
    pnpm eslint --fix --no-error-on-unmatched-pattern {test,assets,admin/assets}/javascripts
    exit_code=\"$?\"
    if [[ $exit_code -ne 0  ]]
    then
      echo \"eslint ainda não ficou feliz -- $exit_code -- fim de jogo\"
      exit
    fi
  fi

  echo ESLINT concluído.

  ## styllint

  echo -n STYLELINT . . .
  pnpm stylelint --allow-empty-input \"assets/**/*.scss\"
  exit_code=\"$?\"
    if [[ $exit_code -ne 0  ]]
    then
      echo \"stylelint não está feliz. Tentando corrigir . . . \"
    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 ainda não está feliz. Isso é triste. Fim de jogo.\"
      exit
    fi
  echo \"CONCLUÍDO!\"

  ## fim stylelint

  ## PRETTIER

  echo -n \"Prettier . . . \"
  if [ -n \"$(find assets -type f \\( -name \"*.scss\" -or -name \"*.js\" -or -name \"*.gjs\" -or -name \"*.hbs\" \\) 2\u003e/dev/null)\" ]; then
    #pnpm prettier --write                  'assets/**/*.{scss,js,gjs,es6,hbs}'
    # echo \"fazendo 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 fez algo!!! -- $?\"
      sleep 5
    fi
  fi
  if [ -n \"$(find admin/assets -type f \\( -name \"*.scss\" -or -name \"*.js\" -or -name \"*.gjs\" -or -name \"*.hbs\" \\) 2\u003e/dev/null)\" ]; then
    #pnpm prettier --write                  'assets/**/*.{scss,js,gjs,es6,hbs}'
    # echo \"fazendo 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 fez algo!!! -- $?\"
      pnpm prettier --check --log-level log \"assets/**/*.{scss,js,gjs,es6,hbs}\"
    fi
  fi
  if [ -n \"$(find test -type f \\( -name \"*.js\" -or -name \"*.gjs\" \\) 2\u003e/dev/null)\" ]; then
    #pnpm prettier --write                  'assets/**/*.{scss,js,gjs,es6,hbs}'
    # echo \"fazendo 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 fez algo!!! -- $?\"
      pnpm prettier --check --loglevel log \"test/**/*.{js,gjs}\"
    fi
  fi
  echo \"Concluído com 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 \"concluído com ember-template-lint --fix --no-error-on-unmatched-pattern assets/javascripts -- com $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ão está feliz. Tentando corrigir em 2 segundos . .. \"
      sleep 2
      echo \"aqui vamos nós!!!\"
      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 ainda não está feliz. Isso é triste. Esperando para te deixar mais triste\"
      sleep 15
    fi
  echo concluído com stree

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


Mas eu também tenho isto, que acho que funciona quase da mesma forma:

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

A única diferença agora parece ser que o linting do core não está feliz com isto (e acho que entendo por que o core encontra e o plugin não, e não há desvantagem em corrigir essas depreciações mais cedo ou mais tarde):


/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 erro, 0 avisos)

E se eu usar bin/lint então eu não tenho que me preocupar que algo mude no linting que exija atualizar meu script de 54 linhas. Certo?

Espere. Documentando-os onde nos repositórios skeleton?

Eu adoraria alguma orientação sobre como eu poderia implementar mudanças metodicamente, embora eu entenda que meu pequeno conjunto de coisas não é realmente problema seu. . . Isso não pertence realmente aqui, mas tentei algumas vezes entender mass-pr, mas ainda não consegui. Eu geralmente apenas copio periodicamente alguns arquivos .whatever de um pull recente do skeleton e espero o melhor.

E existem 16 desses scripts. Eu devo monitorar o repositório e então executá-lo sempre que um deles for atualizado? E vários temas parecem não clonar os repositórios skeleton, então falham ao copiar os arquivos necessários?

E vários falham com algo como sed: can’t read s/default.yml/stree-compat.yml/: No such file or directory ? porque eles não clonam os repositórios skeleton? (Vou abrir um tópico em algum lugar apropriado para isso quando tiver uma chance).

bin/lint usa a configuração de linting do core e, portanto, não suporta temas ou plugins. Se você o usar, provavelmente terá falhas no CI do seu tema/plugin. Por exemplo, até pequenas atualizações de versão do prettier podem fazer mudanças sutis no tratamento de espaços em branco.

Sim, é essencialmente o que os scripts de massa de PR fazem :+1:

update-linting.sh é o que você quer. Outros scripts são para implementações mais especializadas.

Você pode. Ou você pode simplesmente executá-lo novamente de tempos em tempos, quando quiser atualizar a configuração de linting para seu tema/plugin. Como a configuração é totalmente autônoma, uma mudança no core nunca afetará o linting em seus temas/plugin - eles são completamente desacoplados.

Legal! Então eu só preciso executar aquele de vez em quando e ele atualizará todas as verificações de lint. Os outros são para fazer coisas mágicas como ajudar a migrar para o novo ember e outras coisas? Talvez eu esteja começando a entender e eu possa fazer uma lista de repositórios como no exemplo.

Entendi. Eu estava confuso porque não tinha executado pnpm i, então o lint do tema/plugin estava fazendo a coisa errada e o lint principal estava consistente com o github.

Sim, mas eu adoro gastar 5 horas automatizando uma tarefa que posso fazer manualmente em 3 minutos e este parece ser um bom jeito de fazer isso. :rofl: