-
Benjamin Franzke authored
This change is preparatory refactoring in order to support native JavaScript modules (ESM) where a module can't be used both as classic script-src and as ES6 module providing exports at the same time (this was/is possible for AMD as implemented in #95953): `export` is an invalid keyword in non-module scripts and cannot be specified conditionally, that is very different to AMD modules where `define()` can be called conditionally. JavaScriptHandler currently has three execution modes: * If used as script-scr: Call processItems from text content for: * RequireJS configuration * Generic JavaScriptItems processing * If used as AMD module: * Generic JavaScriptItems processing JavaScriptHandler is now separated into the following three concerns: JavaScriptItemProcessor ----------------------- The previous processor "mode" is now available as streamlined JavaScriptItemProcessor module, in order to drop type invariance (it requires parsed objects instead of allowing raw json data or objects) JavaScriptItemHandler --------------------- The previous JavaScriptHandler module that processes text content and calls arbitrary hooks has been simplified to the one usecase that was actually being used: Handling JavaScriptItems by parsing the text content. The extracted JavaScriptItemProcessor is used as backend for the actual work. RequireJSConfigHandler ---------------------- The RequireJS configurator is now available as separate module, as this logic is only needed once and not by other modules. There is no need to keep that functionality in JavaScriptItemProcessor, especially as it has been hidden from AMD modules, which complicated the JavaScriptHandler. This extraction also actually allows to make use of modules in JavaScriptHandler and therefore enables the possibility to share code using JavaScriptItemProcessor. Also the code has been migrated to TypeScript. JavaScriptItemHandler and RequireJSConfigHandler do not export or import code, therefore they are usable as plain targets for script-tags. In addition the JavaScriptItemHandler is now executed asynchronously, which allows the browser to parse DOM in parallel. (synchronous mode is required for RequireJS config, but not for loading of requirejs-modules/instructions, they are asynchronous anyway). FileClipboardCest is adapted to wait more than 1 second, since the rerendering of the clipboard (a new iframe request is made) takes longer than 1 second in some test runs (not locally, but on CI) (note: the default 1 second wait timeout is configured in typo3/sysext/core/Tests/Acceptance/Application.suite.yml, but that's too less in this case). Releases: main Resolves: #96476 Related: #95953 Related: #96323 Change-Id: I48a5751cea03537344e925beba365841e0855dde Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72892 Tested-by: core-ci <typo3@b13.com> Tested-by: Oliver Hader <oliver.hader@typo3.org> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Benjamin Franzke <bfr@qbus.de> Reviewed-by: Oliver Hader <oliver.hader@typo3.org> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Benjamin Franzke <bfr@qbus.de>
a669f117