This would break things like {{subst:iusc|scriptname}} to import a script. But that never really made sense to me anyway and encourages a worryingly magical culture.

In T373834#10115005, @Pppery wrote:

But that never really made sense to me anyway and encourages a worryingly magical culture.

There will definitely be pushback. I'm pretty sure that there is a ticket for the opposite in Lua/Scribunto modules...

Ideally, this would all be MCR, with separate content blobs, but unfortunately, there isn't really the infrastructure to edit multiple content blobs, which makes it less than ideal

Yeah that never made sense to me either. Mixing wikitext and JavaScript seems problematic to me.

I initially thought that "iusc" was just a shortcut for importScript, not a template, and got confused when I saw my scripts weren't loading. I think there should be something like an interpreter keyword that could be used for preprocessing.

I actually am wondering if there should maybe be an entirely different parser for CSS and JavaScript. The reason the parser got turned on for CSS and JavaScript were concerns of bypassing the spam blacklist. However, we can just... not let CSS and JavaScript be interpreted as wikitext at all. Code in one language is not code in another language.

We can always define another global variable which controls this behavior, maybe $wgParseCSSJSAsWikitext.

Change #1071058 had a related patch set uploaded (by Awesome Aasim; author: Awesome Aasim):

[mediawiki/core@master] component: On CSS and JS pages, only parse and pre-save transform comments

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

See T43155 for a number of cases where users currently rely on various features here; there's also T61616. For example:

In T61616#2622575, @Schnark wrote:

Please note that even PST in JS models is (ab-)used. E.g. https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups says: "Other installation method: add {{subst:navpop}} to your current skin's .js page. See below for full installation instructions." And look how many wikis have the same template
https://en.wikipedia.org/wiki/Template:Navpop Or https://en.wikipedia.org/wiki/Template:Js Or https://en.wikipedia.org/wiki/Template:Install_user_script

IMHO this isn't a reason not to deprecate wikitext PST for JS content model, but it will require quite a long transition period to fix all those documentation.

So this definitely needs user-notice, and probably needs a config flag to allow an orderly transition as well.

See also the discussion in T236828: Unexpected PST effect when saving edits to .js pages that were formerly <nowiki>.

The patch for review has a config flag already.

Change #1074701 had a related patch set uploaded (by Awesome Aasim; author: Awesome Aasim):

[mediawiki/extensions/SyntaxHighlight_GeSHi@master] syntaxhighlight: Update to use newly defined `parse` method in CSS/JS content handlers

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

Change #1074701 abandoned by Awesome Aasim:

[mediawiki/extensions/SyntaxHighlight_GeSHi@master] syntaxhighlight: Update to use newly defined `parse` method in CSS/JS content handlers

Reason:

Pppery and SD0001 suggests using a different hook instead of defining `parse` method

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

The Peast library, which is already installed in MediaWiki and has passed security review, supports generating abstract syntax trees for JavaScript. Perhaps a patch could use that to detect where JavaScript comments are.