Vorhersehbarerweise, nehme ich an, stimmt letzteres mit dem überein, was passiert, wenn GitHub Actions ausgeführt werden.
Was ich wirklich gerne hätte, ist, dass das Richtige passiert, wenn ich in VSCode speichere, was, da bin ich mir ziemlich sicher, ein weiteres Problem ist.
Mir ist das auch aufgefallen… Linting in Plugins ist alles Snowflake-Material, wir haben Branches für alten vs. neuen Stil des Lintings in der CI und benötigen eine Menge Setup im Repository.
Ich denke, ein großartiges Ziel ist es, es so zu beheben, dass bin/lint auch für Plugins und Themes funktioniert. Wir haben das noch nicht implementiert, es funktioniert nur für Core und Core-Plugins.
Tatsächlich ist das Linting für Themes/Plugins bewusst vom Core entkoppelt. Sie könnten unterschiedliche Versionen und Konfigurationen der Linting-Tools verwenden. Dies ist wichtig, damit wir Änderungen einführen können, ohne plötzlich das Linting in allen Repositories zu unterbrechen.
Wir könnten wahrscheinlich bin/lint zum Laufen bringen – es müsste in das Plugin-/Theme-Verzeichnis wechseln (cd), pnpm i ausführen und dann alle Linting-Befehle im Kontext dieses Verzeichnisses ausführen.
Das sollte es tun. Die meisten unserer Teammitglieder verwenden VSCode (oder VSCode-Ableitungen), daher optimieren wir darauf. Eslint- und Prettier-VSCode-Plugins suchen nach der „nächstgelegenen“ Installation und Konfiguration für eine bestimmte Datei.
Haben Sie pnpm i im Theme-/Plugin-Verzeichnis ausgeführt? Das ist erforderlich, um dessen Linting-Abhängigkeiten zu installieren, damit VSCode das Richtige finden kann.
Theme/Plugin-Linting unterscheidet sich grundlegend vom Kern. Wir haben themen-/plugin-spezifische Regeln. Themes haben ihre eigenen magischen Globals, über die ESLint Bescheid wissen muss (themePrefix/settings)
Wir achten sehr darauf, dies beizubehalten, dokumentieren es in den Theme/Plugin-Skeleton-Repos und führen Änderungen methodisch über Massen-PRs ein.
Ah, okay. Wir haben Skripte für das automatische Aktualisieren (aus dem Skelett) hier. Diese freundlicher für die Ausführung auf einzelnen Themes/Plugins zu gestalten, könnte ein schönes Projekt sein.
Übrigens, wenn ich sage, dass sie unterschiedliche Konfigurationen haben, meine ich nicht, dass wir die Konfiguration überall duplizieren. Wir haben ein versioniertes lint-configs-Paket, das gemeinsame Konfigurationen für prettier, eslint, stylelint und ember-template-lint enthält. Ein Theme/Plugin auf die neuesten Regeln zu aktualisieren, ist normalerweise nur eine Frage des Erhöhens der lint-configs-Version in der package.json.
Aber ich bin mir ziemlich sicher, dass die Linting-Tests in der GitHub-Aktion fehlschlagen, wenn ich dem Linting folge, das im Plugin durchgeführt wird.
AHA!!! pnpm i scheint das Zauberwort zu sein, das mir gefehlt hat. Ich habe das „pnpm i“ zu meinem Skript hinzugefügt, das Discourse Core aktualisiert, und zu dem, das das Linting durchführt. . .
Hier ist also, was mein Skript tut:
if [[ \"$ARG\" == \"eslint\" ]]
then
# Siehe https://github.com/discourse/.github/blob/main/.github/workflows/discourse-plugin.yml
if [ -f plugin.rb ]
then
echo \"Linting aktuelles Verzeichnis.\"
else
echo \"Nicht auf einem Plugin. Verwende $DEFAULT_PLUGIN\"
cd $DEFAULT_PLUGIN
fi
echo \"LINTING $(pwd)\"
#cd /home/pfaffman/src/literatecomputing/discourse-display-email
# pnpm install
echo \"Mache `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 war unzufrieden -- $exit_code -- versuche zu beheben\"
pnpm eslint --fix --no-error-on-unmatched-pattern {test,assets,admin/assets}/javascripts
exit_code=\"$?\"
if [[ $exit_code -ne 0 ]]
then
echo \"eslint war immer noch unzufrieden -- $exit_code -- Spiel vorbei\"
exit
fi
fi
echo ESLINT fertig.
## styllint
echo -n STYLELINT . . .
pnpm stylelint --allow-empty-input \"assets/**/*.scss\"
exit_code=\"$?\"
if [[ $exit_code -ne 0 ]]
then
echo \"stylelint ist unzufrieden. Versuche zu beheben . . . \"
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 ist immer noch unzufrieden. Das ist traurig. Spiel vorbei.\"
exit
fi
echo \"FERTIG!\"
## Ende 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 \"mache 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 hat etwas getan!!! -- $?\"
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 \"mache 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 hat etwas getan!!! -- $?\"
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 \"mache 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 hat etwas getan!!! -- $?\"
pnpm prettier --check --loglevel log \"test/**/*.{js,gjs}\"
fi
fi
echo \"Fertig mit 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 \"fertig mit ember-template-lint --fix --no-error-on-unmatched-pattern assets/javascripts -- mit $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 ist unzufrieden. Versuche in 2 Sekunden zu beheben . .. \"
sleep 2
echo \"Auf geht'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 ist immer noch unzufrieden. Das ist traurig. Warte, um dich noch trauriger zu machen\"
sleep 15
fi
echo fertig mit stree
echo \"rubocop!\"
bundle exec rubocop -A $(find . -name \"*.rb\"|grep -v gems)
exit_code=\"$?\"
if [[ $exit_code -ne 0 ]]
then
echo \"fertig mit rubocop -- $exit_code\"
sleep 15
fi
exit
fi
Aber ich habe auch das hier, das meiner Meinung nach fast genauso funktioniert:
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
Der einzige Unterschied scheint jetzt zu sein, dass Core Linting über dies unglücklich ist (und ich glaube, ich verstehe, warum Core es findet und das Plugin nicht, und es gibt keinen Nachteil, diese Veraltungen früher als später zu beheben):
/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 problem (1 error, 0 warnings)
Und wenn ich bin/lint verwende, muss ich mir keine Sorgen machen, dass sich etwas am Linting ändert, das ein Update meines 54-zeiligen Skripts erfordert. Oder?
Warte. Dokumentieren sie es wo in den Skeleton-Repositories?
Ich würde mich gerne beraten lassen, wie ich Änderungen methodisch einführen kann, auch wenn ich verstehe, dass meine kleine Menge an Dingen nicht wirklich Ihr Problem ist. . . Das gehört hier eigentlich nicht hin, aber ich habe ein paar Mal versucht, mass-pr zu verstehen, hatte aber noch keinen Erfolg. Normalerweise kopiere ich nur periodisch einige .whatever-Dateien aus einem aktuellen Pull des Skeletons und hoffe das Beste.
Und es gibt 16 dieser Skripte. Muss ich das Repository beobachten und es dann ausführen, wann immer eines davon aktualisiert wird? Und eine Reihe von Themes scheinen die Skeletons nicht zu klonen, sodass sie die erforderlichen Dateien nicht kopieren können?
Und mehrere scheinen mit etwas wie sed: can’t read s/default.yml/stree-compat.yml/: No such file or directory fehlzuschlagen, weil sie die Skeleton-Repositories nicht klonen? (Ich werde ein Thema an einer geeigneten Stelle dafür starten, sobald ich Gelegenheit dazu habe).
bin/lint verwendet die Linting-Konfiguration des Kerns und unterstützt daher keine Themes oder Plugins. Wenn Sie es verwenden, werden Sie wahrscheinlich Fehler in Ihrem Theme/Plugin CI erhalten. Zum Beispiel können selbst winzige Versions-Upgrades von Prettier subtile Änderungen in der Behandlung von Leerraum verursachen.
Ja, das ist im Grunde das, was die Mass-PR-Skripte tun
update-linting.sh ist dasjenige, das Sie wollen. Andere Skripte sind für spezialisiertere Rollouts.
Das können Sie tun. Oder Sie können es einfach in regelmäßigen Abständen erneut ausführen, wenn Sie die Linting-Konfiguration für Ihr Theme/Plugin aktualisieren möchten. Da die Konfiguration vollständig in sich geschlossen ist, wirkt sich eine Änderung im Kern niemals auf das Linting in Ihren Themes/Plugins aus – sie sind vollständig entkoppelt.
Cool! Ich muss also nur ab und zu dieses eine ausführen und es aktualisiert alle Lintings. Die anderen dienen dazu, magische Dinge zu tun, wie bei der Migration zu neuem Ember und so weiter? Vielleicht fange ich an, es zu verstehen, und ich kann eine Liste von Repositories wie im Beispiel erstellen.
Verstanden. Ich war verwirrt, da ich pnpm i nicht ausgeführt hatte, sodass das Theme/Plugin-Lint das Falsche tat und das Core-Lint konsistent mit GitHub war.
Ja, aber ich liebe es, 5 Stunden damit zu verbringen, eine Aufgabe zu automatisieren, die ich von Hand in 3 Minuten erledigen kann, und das scheint ein guter Weg dafür zu sein.
