looks okau to me.
I think we should note somewhere (at release page or system requirement), that nomodule will be dropped at some point of 4.x, maybe even in 4.1

I think we should note somewhere (at release page or system requirement), that nomodule will be dropped at some point of 4.x, maybe even in 4.1

Sure, but only if we ever come to an agreement on how we move forward with Js, transpiling, etc ?

you know what I thinking,
we need es5 fallback only for a scripts that may be used on frontend,
because whole backend is unusable in old browsers anyway (I can actually login, but not much can do).

because whole backend is unusable in old browsers anyway

The backend is unusable with the default template. If I fork Atum and use bs4 css (patching the changed classes with some extends or whatever) the backend should be still fine on IE11

@wilsonge any input here?

If I fork Atum and use bs4 css

It not only the styling, but much of JS errors (I tried on current 4.0-dev branch, without this PR)

but much of JS errors

There are known errors right now as people removed some polyfills without our tools adding them back. Basically, the tools are not really transpiling properly the es6 files. Partially this is fixed with #32300 but I think there will be a bit more tweaking required

@Fedik can you post some of those errors?

Basically, the tools are not really transpiling properly the es6 files

yeah I suspect that also,
there was something about undefined require(), and some others,
I can try to run again sometime later and copy some of them, if it makes sense ?

there was something about undefined require(), and some others,

@Fedik the require() errors should be fixed with #32459

can you post some of those errors?

here is IE 11 a fresh screenshot of errors, from Dashboard view:

it not related to current PR, just for info as you asked

Thanks, so there are quite some problems here:

• require() comes from a missing rollup plugin fixed with #32485
• closest() right now the the babel is not injecting missing parts AFAIK
• Object doesn't support property I have no clue, this is also affecting the webcomponent polyfill which is not patched in any way from us, I have to dig this one

EDIT: it seems there's a tag missing: <meta http-equiv="X-UA-Compatible" content="IE=11" />

Are the attributed nomodule: true and module: defer the opposites of each other - asking for a friend

Are the attributed nomodule: true and module: defer the opposites of each other - asking for a friend

They are exclusive, type=module means the script is loaded with defer and ONLY by 2017+ browesers also these browsers will ignore the nomodule scripts.

Browsers up to 2017 (eg without module support) will ignore the type=module (they don't know how to handle it) but we're setting also the defer so we have the same order of execution

ok - thanks. as long as it all gets documented

Looks like some leftover test code in code mirror logging mode to console in https://github.com/joomla/joomla-cms/pull/32315/files#diff-1ae7d38a00585728880c44a33b57e666285099ba9879ffc55b91cdb7f43fadb1R53

I don't see any other issues thus far.

@krileon gone, thanks

I have tested this item ✅ successfully on 05119cd

I like, but would be nice to explain a bit more how extension devs can benefit from this.

@brianteeman @laoneo ok so then I'll write a doc about this and also cover all the JS parts (API, passing data from PHP to client-side, etc)

The video is clear about "the transitioning to modern JavaScript" and there is plenty of information about modern JavaScript around. So, you can include in the documentation a brief summary.

What I'm missing is a guide about how Joomla is doing the transition and what an extension developer should do to follow the steps. What the CMS provides and what the extension developer must do in terms of JavaScript code modernization for Joomla.

how Joomla is doing the transition

• Started with the bootstrap PR: #31990
• Then transitioned the Web Components/Custom Elements #32171
• Finally this PR transitions all the remaining scripts

what an extension developer should do to follow the steps

• If the dev is using Web Assets then the change is a simple switch of the definitions of the scripts (assuming that the source is modern JS and there is a bundler capable of producing ES2017 and ES5 scripts, continue reading).
  Eg legacy script is, let's say some jQuery, so:

    {
       "name": "com_example.awesome-script",
       "type": "script",
       "uri": "com_example/awesome-script.min.js",
       "dependencies": [
         "core"
       ],
       "attributes": {
         "defer": true
       }

Modern way assumes that the script has a source (modern JS) that transpiles to 2 files, one ES2017 and one ES5 (the one with -es5):

    {
       "name": "com_example.awesome-script.es5",
       "type": "script",
       "uri": "com_example/awesome-script-es5.min.js",
       "dependencies": [
         "core"
       ],
       "attributes": {
         "nomodule": true,
        "defer": true
       },
    }
    {
       "name": "com_example.awesome-script",
       "type": "script",
       "uri": "com_example/awesome-script.min.js",
       "dependencies": [
         "com_example.awesome-script.es5"
       ],
       "attributes": {
         "type": "module"
       }
  }

• If the dev is using the HTMLHelpr then the change is just an additional call.
  Eg: Legacy:

HTMLHelper::_('script', 'com_example/awesome-script.min.js', ['version' => 'auto', 'relative' => true], ['defer' => true]);

Eg Modern:

HTMLHelper::_('script', 'com_example/awesome-script-es5.min.js', ['version' => 'auto', 'relative' => true], ['defer' => true, 'nomodule' => true]);
HTMLHelper::_('script', 'com_example/awesome-script.min.js', ['version' => 'auto', 'relative' => true], ['type' => 'module']);

Mind that the legacy script com_example/awesome-script.min.js was theoretically rewritten as modern JS and was transpiled to ES2017 with the same name and then a transpiled ES5 was produced by a bundler and had a theoretical name com_example/awesome-script-es5.min.js. But this is the convention Joomla is using, devs can use their own naming convention here, Joomla will not impose anything in this part.

What the CMS provides

Joomla has a set of tools for compiling a modern script to ES2017 and ES5 files. Devs can use Rollup, Webpack, Parcel, ESBuild, SnowPack, or any other bundler out there. The scripts for the bundling live at https://github.com/joomla/joomla-cms/tree/4.0-dev/build/build-modules-js/javascript and devs can even use them as-is if they develop on top of the Joomla repo (this is probably an antipattern, but...) or fork them for their own benefit.

Great, thanks for the explanation.

HTMLHelper::_('script', ..

for note: this is now forbidden in Joomla 4 ?

for note: this is now forbidden in Joomla 4

I'm with you here but then once this merged we need another PR to remove the few instances of HTMLHelper::_('script'. I don't want to invalidate the one good test. Finding people willing to test such PRs is hard...

hmhm then I have missed it when replaces all to WebAsset,
yea, it need to be done separately

@dgrammatiko I have tested this, it's awesome, I mean it really works!

I've updated my commit #32510 to reflect these changes.

I noted that both my field.color-picker es6 and es5 coming both use TinyColor es5 for some reason, perhaps that's what it was supposed to do, however I tried to use import TinyColor from '@ctrl/tinycolor/dist/public_api.js', same result? Perhaps that's a non-issue at this point.

I have tested, it works. IE11 explodes with errors, but nevermind ?

I have tested this item ✅ successfully on 05119cd

I have tested this item ✅ successfully on 05119cd

RTC

I have tested, it works. IE11 explodes with errors

I know, I commented out the required lines for IE https://github.com/joomla/joomla-cms/pull/32315/files#diff-7973fa8a952791298a25a8354216ed84a7476bf991fce4be84f05cb1d91f2bce because we might want to abstract (if possible) the Babel runtime (it's 6kb that will be included in each script) but besides that, we need a list of DOM polyfills that Babel is not injecting (eg htmlElement.colsest() ). Also, the webcomponents polyfill should include the file webcomponents-bundle.js instead of bundles/webcomponents-sd-ce-pf.js. In short, this is a bug we can fix, I just didn't want to blow this PR even further. I will do the patches in another PR or PRs

...because we might want to abstract (if possible) the Babel runtime (it's 6kb that will be included in each script) but besides that, we need a list of DOM polyfills that Babel is not injecting

you wanted to say that we need jQuery? ?

you wanted to say that we need jQuery?

I some cases also Mootools ?

@wilsonge can we have a decision here?

@dgrammatiko I think with this PR, it's a good opportunity to change ESlint with @babel/eslint-parser, this one allows static properties to be parsed, something I need for the color-picker called static formAssociated = true;.

@thednp joomla is using the Airbnb rules for eslint and I don’t see why we need to change this. Airbnb is extremely well documented. Also you can’t use formInternals as it is poorly supported

Also onformdata isn't good enough? Seems well supported.

Safari doesn’t support it so: no

ref https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onformdata

Btw I already gave you the solution

@dgrammatiko Now I have a problem when using node version 12:

I.e. it breaks here:

https://github.com/joomla/joomla-cms/blob/4.0-dev/build/build-modules-js/javascript/compile-to-es2017.es6.js#L1

With node version 14 I don't have that problem.

At least one other person could reproduce that, i.e. same problem on same OS (Linux) with node v12, and no problem anymore after removing node and installing v14.

Any idea?

@wilsonge What version of node do we require?

@richard67 Can you change it to: const { access } = require('fs').promises; ? Does that solve the problem?

Also according to https://nodejs.org/en/about/releases/ v10 goes EOL next month, so v12 should be set as the minimum at the end of April.

@richard67 Can you change it to: const { access } = require('fs').promises; ?

Not sure if I can. Can you advise me? Does it need a text editor for that?
...
Joking ;-)

Does that solve the problem?

It solves the problem on node v12 on my Linux VM. Will see in a few minutes if it still works with node v14 on my Windows VM.

It solves the problem on node v12 on my Linux VM.

Well, the 'fs/promises' is just a newer syntax of the same thing. Everything should be ok. Node is confusing with the rolling versions but I guess I should have tested this

Everything should be ok.

It means no need for a fix? Or it means your suggested fix is ok? If the latter: Could you make the necessary PR?

so the question arise what should be the node and npm versions ? for testing of course

sure: #32686

so the question arise what should be the node and npm versions ? for testing of course

Till the end of April v10 should be ok but I guess the project should raise the minimum to v12 before v10 goes EOL. Also whatever you do MARK the date (end of April) as you have to do this every year since Javascript the language gets a new version every year (so nodejs just follows the ecmascript releases)

so the question arise what should be the node and npm versions ? for testing of course