[5.2] [bugfix] Use iife for the scripts core and load validate as module

[dgrammatiko]

Pull Request for Issue #43714 .

Summary of Changes

Use iife instead of esm for the script core.js and load the script validate.js with a type=module

Testing Instructions

• Apply the PR
• run npm install
• Check that authenticating in the administrator works
• Create a new article, don't add anything and press save, the validation error should appear

Actual result BEFORE applying this Pull Request

Leaking variables in the global scope

Expected result AFTER applying this Pull Request

NO leaking variables in the global scope

Link to documentations

Please select:

• Documentation link for docs.joomla.org:

• No documentation changes for docs.joomla.org needed

• Pull Request link for manual.joomla.org:

• No documentation changes for manual.joomla.org needed

@Fedik

[Fedik]

This is no go, sorry.

I would suggest to keep for 5.1 the same what you did for 4.4 (will be upmerged).
And set core and validator to type=module for 5.2 as a new feature.

Please, without this huge code move, that you made in core.js.
Just window.Joomla = Joomla; is enough. Having 100 window.Joomla.foobar = .. is very bad idea.
Thanks.

[Fedik]

If you have a problems with eslint, just add:

/* global Joomla */

At top of the file. Like we have for TinyMCE

joomla-cms/build/media_source/plg_editors_tinymce/js/tinymce.es6.js

Line 9 in 37eaa18

/* global tinymce, tinyMCE */

[dgrammatiko]

I would suggest to keep for 5.1 the same what you did for 4.4 (will be upmerged).
And set core and validator to type=module for 5.2 as a new feature.

I don't see any problems with the change from defer to type=module. Let me explain:

• the defer script in 4.4 has a use strict but with the type=module this is inferred
• Both defer and type=module load the script as deferred
• The only difference is that in the 4.4 the class JFormValidator is globally registered but I could attach it to the window and have the same effect.

In sort this change shouldn't be assumed as a breaking change as it isn't

I'll change the window.Joomla refs

[Fedik]

There no problem to set type=module as it is, however they may be extensions that doing "script optimisation" merging non module scripts etc. It will change behavior slightly, to them.

It is not a big deal, but I would keep it safe, and would not to do such changes in patch release.

[dgrammatiko]

It is not a big deal, but I would keep it safe, and would not to do such changes in patch release.

I'm willing to take full responsibility for this if the maintainers trust me 🙋‍♂️

[Fedik]

Then I leave you to maintainers 😄

[Fedik]

Please add one more globals for window.punycode = punycode; (as it may used by some script).

And then release manages can decide, what to do with the PR.

[dgrammatiko]

Please add one more globals for window.punycode = punycode; (as it may used by some script).

Done, I guess you could raise this to the maintainers

[Fedik]

I have tested this item ✅ successfully on 2c1f421

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43758.}

[viocassel]

I have tested this item ✅ successfully on 2c1f421

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43758.}

[alikon]

RTC

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43758.}

[bembelimen]

Hey @dgrammatiko thanks for this PR. Just to understand, isn't this a B/C break, if someone e.g. made an override of the "old" core/validation script and now it's loaded as a module?

[dgrammatiko]

No, type=module means:

• use strict by default
• Deferred
• Reduced scope

the reduced scope in this case is irrelevant as the classes are exposed as global vars. In sort there won’t be any issue!

FWIW: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#other_differences_between_modules_and_standard_scripts

[bembelimen]

Ok, I just saw, that after the upmerge something similar was done in 4.4, could you (@dgrammatiko ) please check, if the changes were correct and if this PR is still needed? Thank you!

[dgrammatiko]

@bembelimen these changes are still better than the code in 4.4. ES modules should be the default way of serving js in 2024...

[HLeithner]

I rebased this for 5.2, not sure if this comes to 5.2 or not @bembelimen @Hackwar