Resolving the `this-property-fallback` deprecation

Dev
1

Background

Essentially, if you’re using something like {{foo}} in a handlebars template to reference a property on the controller/component, then it needs to be updated to {{this.foo}}.

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

To get Discourse through the Ember 4.x upgrade, we introduced a backwards-compatibility shim so that themes and plugins did not need to rush through this change. However, it’s not feasible to maintain this shim indefinitely, so we need to get themes and plugins updated to the modern syntax.

Deprecation

In the latest version of Discourse, using the legacy syntax will cause a deprecation message to be printed to the console. It’ll look something like this:

DEPRECATION: [PLUGIN discourse-calendar] The `loading` property path was used in the `discourse/plugins/discourse-calendar/discourse/templates/admin-plugins-calendar.hbs` template without using `this`. This fallback behavior has been deprecated, all properties must be looked up on `this` when used in the template: {{this.loading}}

As with any other deprecation, we will slowly increase the visibility of this warning, until we eventually remove the backwards-compatibility shim. We are tentatively targetting Q2 2025 for final removal, but will adjust that based on real-world data.

Upgrading your code

For small themes/plugins, you can update the templates manually to add this. before any property name.

To make the transition easier for larger themes/plugins, we’ve introduced a new ember-template-lint rule which includes an auto-fixer.

So, if you use the latest version of our standard linting configuration (as per the plugin skeleton and the theme skeleton), then all affected code will be automatically updated next time you run ember-template-lint --fix.

If you have any questions/concerns, please let us know below!

3 Likes
2

That’s awesome! In one of my plugins where (I think I have) properly updated the lint config, I see a whole buch of instances of {{this.blah}} that I’m pretty darn sure weren’t there until recently. I can’t overstate how cool that is. :tada: :clinking_glasses: :beers:

It would be nice if there were some automated way to copy/remove the proper files in each plugin when there was an update to the skeleton. (I may or may not have contrived to do that by hand this time.) Maybe it’d be possible to stick a little bash script into the skeleton that would check for plugin.rb in the current directory, and if it was there, it could copy stuff from where the script was into the current directory. Something like that.

1 Like
3

We haven’t really publicised it, but you might be interested in GitHub - discourse/mass-pr: A tool for applying automated changes across a large number of GitHub repositories. We use it to apply these kinds of changes across the 600+ theme/plugin repos we maintain.

So in this case, I run something like:

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

and it updates the skeleton stuff, autofixes all linting, and creates the PR on GitHub.

Then we have another script to handle the merging: GitHub - discourse/mass-merge: A script for mass-approving and merging Dependabot pull requests

Definitely pr-welcome on a lighter-weight update script though! These ones are a bit heavy-handed if you only have one repo to update.

3 Likes