Sounds like a good plan to me. ideally, i want to actually make deprecations of modules even more visible while running code, but it's a bit difficult to identify people who might actually be able to do something with such a warning, vs people who would be heavily annoyed by it....

The front-end standards group discussed it today, here is a summary:

• We think the proposal makes sense, it can help developers identify deprecated modules and encourage updating existing code.

• We should inject a script statement when the module is loaded, to log a message to the developer console. We should not do it into the startup manifest.

• We should make clear what "deprecate" means on mediawiki.org.
  • We can have a first and a second warning, with two different messages logged to the browser console. This can define an expiration date and insist on updating existing code.

Change 299090 had a related patch set uploaded (by Jdlrobson):
POC: ResourceLoader should support deprecation of modules

https://gerrit.wikimedia.org/r/299090

Apologies for not making this discussion - I completely lost track of time for the frontend standards meeting. Let me throw up a proof of concept for discussion.

I've tried to make this as flexible as possible.
A ResourceLoader module can set a deprecated field which can be a boolean or an array.
If an array it can provide a message key which will be outputted to the console which could potentially define an expiration date/migrate path.
I hope this is a good first step.

Change 299090 merged by jenkins-bot:
resourceloader: Implement 'deprecated' option for FileModule

https://gerrit.wikimedia.org/r/299090