Behebung der `this-property-fallback`-Veraltung

Hintergrund

Im Wesentlichen muss alles, was Sie wie {{foo}} in einer Handlebars-Vorlage verwenden, um auf eine Eigenschaft des Controllers/der Komponente zu verweisen, zu {{this.foo}} aktualisiert werden.

Upstream-Informationen: Property Fallback Lookup | Ember.js - Deprecations

Um Discourse durch das Ember 4.x-Upgrade zu bringen, haben wir einen Abwärtskompatibilitäts-Shim eingeführt, damit Themes und Plugins diese Änderung nicht überstürzen mussten. Es ist jedoch nicht praktikabel, diesen Shim auf unbestimmte Zeit beizubehalten, daher müssen wir Themes und Plugins auf die moderne Syntax aktualisieren.

Veraltung

In der neuesten Version von Discourse führt die Verwendung der Legacy-Syntax zu einer Verwarnungsmeldung, die in der Konsole ausgegeben wird. Sie sieht ungefähr so aus:

DEPRECATION: [PLUGIN discourse-calendar] Die `loading`-Eigenschaft wurde im Template `discourse/plugins/discourse-calendar/discourse/templates/admin-plugins-calendar.hbs` ohne Verwendung von `this` verwendet. Dieses Fallback-Verhalten wurde veraltet, alle Eigenschaften müssen bei der Verwendung im Template auf `this` nachgeschlagen werden: {{this.loading}}

Wie bei jeder anderen Veraltung werden wir die Sichtbarkeit dieser Warnung langsam erhöhen, bis wir schließlich den Abwärtskompatibilitäts-Shim entfernen. Wir peilen vorläufig das zweite Quartal 2025 für die endgültige Entfernung an, werden dies aber basierend auf realen Daten anpassen.

Aktualisieren Ihres Codes

Für kleine Themes/Plugins können Sie die Vorlagen manuell aktualisieren, um this. vor jedem Eigenschaftsnamen hinzuzufügen.

Um den Übergang für größere Themes/Plugins zu erleichtern, haben wir eine neue ember-template-lint-Regel eingeführt, die einen automatischen Fixer enthält.

Wenn Sie also die neueste Version unserer Standard-Linting-Konfiguration verwenden (gemäß dem Plugin-Skeleton und dem Theme-Skeleton), werden alle betroffenen Codes beim nächsten Ausführen von ember-template-lint --fix automatisch aktualisiert.

Wenn Sie Fragen/Bedenken haben, lassen Sie es uns bitte unten wissen!

6 „Gefällt mir“

Das ist großartig! In einem meiner Plugins, in dem ich (glaube ich) die Lint-Konfiguration richtig aktualisiert habe, sehe ich eine ganze Reihe von Instanzen von {{this.blah}}, von denen ich ziemlich sicher bin, dass sie nicht erst kürzlich dort waren. Ich kann nicht genug betonen, wie cool das ist. :tada: :clinking_glasses: :beers:

Es wäre schön, wenn es eine automatisierte Möglichkeit gäbe, die richtigen Dateien in jedem Plugin zu kopieren/entfernen, wenn es ein Update des Skeletts gibt. (Ich habe es dieses Mal vielleicht von Hand erledigt, vielleicht auch nicht.) Vielleicht wäre es möglich, ein kleines bash-Skript in das Skelett einzufügen, das nach plugin.rb im aktuellen Verzeichnis sucht, und wenn es vorhanden ist, könnte es Dinge von dort, wo sich das Skript befindet, in das aktuelle Verzeichnis kopieren. So etwas in der Art.

1 „Gefällt mir“

Wir haben es nicht wirklich öffentlich gemacht, aber vielleicht interessiert Sie GitHub - discourse/mass-pr: A tool for applying automated changes across a large number of GitHub repositories. Wir verwenden es, um diese Art von Änderungen auf die über 600 Theme/Plugin-Repositories anzuwenden, die wir pflegen.

Hier führe ich also etwas aus wie:

GITHUB_TOKEN=... pnpm mass-pr \
  --message "DEV: Update linting" \
  --branch "update-linting" \
  --script scripts/update-js-linting.sh \
  discourse-solved \
  discourse-assign \
  ...

und es aktualisiert die Skeleton-Sachen, behebt automatisch alle Linting-Fehler und erstellt den PR auf GitHub.

Dann haben wir ein weiteres Skript zur Abwicklung des Mergens: GitHub - discourse/mass-merge: A script for mass-approving and merging Dependabot pull requests

Auf jeden Fall #pr_welcome für ein leichteres Update-Skript! Diese sind etwas übertrieben, wenn Sie nur ein Repository aktualisieren müssen.

5 „Gefällt mir“

Nein. Wirklich? Das ist ja fantastisch!

Ich kann es kaum erwarten, es auszuprobieren, aber ich konnte es auch kaum erwarten, Ihnen zu danken.

Nein. Ein Skript ist 4x einfacher zu warten als zwei, und wenn ihr das verwendet, dann will ich das auch verwenden.

Echt cool.

Danke, David! Das ist fantastisch.

Zuerst hat es etwas gedauert, bis ich herausfand, dass ich pnpm install ausführen muss.

Und jetzt habe ich das hier:

#!/usr/bin/env bash
# sync-with-skeleton -- geht davon aus, dass Sie sich in einem befinden
today=$(date +"%Y-%m-%d")
repo=$(grep url .git/config | sed -E 's/.*:([^\\/]+\\/[^.]+).*/\\1/')
cd ~/src/discourse-repos/mass-pr
GITHUB_TOKEN=$GITHUB_TOKEN pnpm mass-pr \
--message "DEV: Update GitHub workflows" \
--branch "sync-with-skeleton-$today" \
--script scripts/update-workflows.sh \
$repo

Es wäre besser, wenn es zum Beispiel nach einer plugin.rb im aktuellen Verzeichnis suchen würde und vielleicht sogar prüfen würde, ob das Repository existiert, aber es ist das, wofür ich heute Zeit hatte. Oder ich könnte es als PR einreichen und es könnte in das Verzeichnis wechseln, in dem es sich befand.

Und es hat mir auch gezeigt, warum ich Dinge als PRs einreichen sollte, auch wenn es nur ich bin. Vielen, vielen Dank.

2 „Gefällt mir“