Risoluzione della deprecazione `this-property-fallback`

Sviluppatore
1

Contesto

Essenzialmente, se stai usando qualcosa come {{foo}} in un template handlebars per fare riferimento a una proprietà sul controller/component, allora deve essere aggiornato a {{this.foo}}.

Informazioni upstream: Property Fallback Lookup | Ember.js - Deprecations

Per far passare Discourse attraverso l’aggiornamento a Ember 4.x, abbiamo introdotto uno shim di retrocompatibilità in modo che temi e plugin non dovessero affrettare questa modifica. Tuttavia, non è fattibile mantenere questo shim indefinitamente, quindi dobbiamo aggiornare temi e plugin alla sintassi moderna.

Deprecazione

Nell’ultima versione di Discourse, l’uso della sintassi legacy causerà la stampa di un messaggio di deprecazione nella console. Sarà simile a questo:

DEPRECATION: [PLUGIN discourse-calendar] Il percorso della proprietà `loading` è stato utilizzato nel template `discourse/plugins/discourse-calendar/discourse/templates/admin-plugins-calendar.hbs` senza usare `this`. Questo comportamento di fallback è stato deprecato, tutte le proprietà devono essere cercate su `this` quando utilizzate nel template: {{this.loading}}

Come per qualsiasi altra deprecazione, aumenteremo lentamente la visibilità di questo avviso, fino a quando non rimuoveremo definitivamente lo shim di retrocompatibilità. Stiamo provvisoriamente puntando al Q2 2025 per la rimozione finale, ma adegueremo ciò in base ai dati del mondo reale.

Aggiornamento del codice

Per temi/plugin di piccole dimensioni, puoi aggiornare manualmente i template per aggiungere this. prima di qualsiasi nome di proprietà.

Per rendere la transizione più semplice per temi/plugin di grandi dimensioni, abbiamo introdotto una nuova regola ember-template-lint che include un auto-fixer.

Quindi, se utilizzi l’ultima versione della nostra configurazione di linting standard (come da plugin skeleton e theme skeleton), tutto il codice interessato verrà aggiornato automaticamente la prossima volta che eseguirai ember-template-lint --fix.

Se hai domande/dubbi, faccelo sapere qui sotto!

6 Mi Piace
2

Fantastico! In uno dei miei plugin dove (credo di aver) aggiornato correttamente la configurazione di linting, vedo un sacco di istanze di {{this.blah}} che sono abbastanza sicuro non fossero lì fino a poco tempo fa. Non posso sottolineare quanto sia fantastico. :tada: :clinking_glasses: :beers:

Sarebbe bello se ci fosse un modo automatizzato per copiare/rimuovere i file corretti in ogni plugin quando c’è un aggiornamento dello scheletro. (Potrei averlo fatto a mano questa volta, o meno.) Forse sarebbe possibile inserire un piccolo script bash nello scheletro che controlli la presenza di plugin.rb nella directory corrente e, se presente, possa copiare elementi da dove si trova lo script nella directory corrente. Qualcosa del genere.

1 Mi Piace
3

Non l’abbiamo pubblicizzato molto, ma potresti essere interessato a GitHub - discourse/mass-pr: A tool for applying automated changes across a large number of GitHub repositories. Lo utilizziamo per applicare questo tipo di modifiche a oltre 600 repository di temi/plugin che manteniamo.

Quindi, in questo caso, eseguo qualcosa del tipo:

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

e aggiorna le cose dello scheletro, corregge automaticamente tutto il linting e crea la PR su GitHub.

Abbiamo poi un altro script per gestire il merging: GitHub - discourse/mass-merge: A script for mass-approving and merging Dependabot pull requests

Sicuramente #pr_welcome per uno script di aggiornamento più leggero! Questi sono un po’ troppo pesanti se hai solo un repository da aggiornare.

5 Mi Piace
4

No. Davvero. È fantastico!

Non vedo l’ora di provarlo, ma non vedevo l’ora nemmeno di ringraziarti.

No. Uno script è 4 volte più facile da mantenere di due, e se lo state usando voi, allora è quello che voglio usare.

Fantastico.

5

Grazie, David! È fantastico.

Innanzitutto, ci ho messo un po’ per capire che devo eseguire pnpm install.

E ora ho questo:

#!/usr/bin/env bash
# sync-with-skeleton -- assumes that you're in a 
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

Sarebbe meglio se, ad esempio, controllasse la presenza di un plugin.rb nella directory corrente e magari anche se il repository esiste, ma è quello che ho avuto il tempo di fare oggi. Oppure potrei inviarlo come PR e potrebbe passare alla directory in cui vive.

E mi ha anche insegnato perché dovrei inviare le cose come PR anche quando ci sono solo io. Grazie mille.

2 Mi Piace