1. 18 Jun, 2022 1 commit
  2. 07 May, 2022 1 commit
  3. 04 May, 2022 1 commit
  4. 06 Apr, 2022 1 commit
  5. 31 Mar, 2022 1 commit
  6. 29 Jan, 2022 1 commit
    • Stefan Bürk's avatar
      [TASK] Revamp phpstan config and handling · 997722b8
      Stefan Bürk authored and Christian Kuhn's avatar Christian Kuhn committed
      We currently have the situation that phpstan is
      hard to update and maintain due to the phpstan
      config file that sets very specific rulesets.
      This is unfortunate since phpstan tends to change
      and rename rules at will.
      The general usage API of phpstan is basically as
      follows: Have a slim config file that sets the
      basic level. Then maintain a 'baseline' file that
      lists violations, using the --generate-baseline
      command option. The todo job for people working
      on phpstan errors is then to look at the baseline
      file, pick up some issues, fix them, then re-generate
      baseline. When baseline is small enough, the level
      is raised, a new baseline is generated, and the
      fix-job starts again.
      The patch does exactly this: The existing config
      is dropped and runTests.sh receives a command to
      generate baseline.
      With this in place, we can easily raise phpstan
      to a PHP 8.1 compatible version:
      > composer req friendsoftypo3/phpstan-typo3:"^0.9.0" --dev
      > composer req phpstan/phpstan:"^1.4.3" --dev
      > Build/Script/runTests.sh -s phpstanGenerateBaseline
      This initialy adds about 4000 ignores to the baseline
      with level 3, but we can reduce this drastically with
      just a couple of dedicated patches, soon.
      The config is heavily streamlined and for instance does
      *not* ignore tests anymore, which actually finds a ton
      of misuses and bugs within tests and classes.
      Resolves: #96675
      Releases: main, 11.5
      Change-Id: I0e7ff7aa796e59a2c5eedde0b673f741f8b87dea
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73037
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  7. 24 Jan, 2022 1 commit
  8. 21 Jan, 2022 1 commit
    • Benjamin Franzke's avatar
      [TASK] Migrate backend TypeScript to ECMAScript modules (ESM) · 47481cbd
      Benjamin Franzke authored
      Use the JavaScript module and importmap Feature introduced
      in #96510 to import JavaScript as native browser modules
      (commonly referred to as ES6 modules, or short ESM).
      To be specific: we actually use ES2020 (ES11) modules,
      as we import modules dynamically via import() in
      combination with an importmap (#96510).
      Backwards compatibility for existing RequireJS imports
      is provided by a shim as introduced in #96510.
      How to (re)view this change
      Exclude all automatic TypeScript/JavaScript/lockfile changes with:
      git show --oneline -- . \
          ':(exclude)typo3/sysext/*.js' \
          ':(exclude)Build/Sources/TypeScript/*.ts' \
      git show --oneline -- $(find Build/ \
          -name DragUploader.ts -o \
          -name FormEngine.ts -o \
          -name Helper.ts -o \
          -name CKEditorLoader.ts -o \
          -name CodeMirrorElement.ts)
      Gruntfile & tsconfig.json
      Gruntfile is adapted to transform all our dependencies into ES6
      Also tsconfig is adapted to emit es2020 modules (es2020 is required
      for dynamic module imports with import()).
      Also allowSyntheticDefaultImports is enabled while esModuleInterop
      is now longer needed as we target ES modules and therefore removed.
      allowSyntheticDefaultImports had been enabled implicitly by
      esModuleInterop, we still need this enabled as the type declarations
      of our dependencies still imply AMD/CJS exports
      (which we fix in our build steps).
      JSUnit configuration is moved from testing-framework into core for more
      flexibility when adaptions are required. The testing is revamped
      to use karma-rollup-preprocessor instead of karma-requirejs in
      order to support the newly compiled ES6 modules.
      TypeScript Exports and Imports
      All export and import definitions have been auto-converted
      from AMD pseudo import/exports to native ES6 import/exports.
      Executed commands:
        find Build/Sources/TypeScript/ -name '*.ts' -exec sed -i \
          -e 's/export =/export default/' \
          -e 's/ = require(\(.*\))/ from \1/g' \
          -e "s/^import 'tablesort';/import Tablesort from 'tablesort';/" \
          '{}' +
      Note that the switch from `export =` to `export default` is
      not considered breaking because the require-adapter in
      requirejs-loader wil transparently resolve the .default in moduls.
      This is possible because AMD modules could not use `export =`
      and `export {}` (for named exports) at the same time.
      Explicitly use RequireJS for CodeMirror and ext:form for now
      CodeMirror can't be easily transformed to ES6 right now,
      therefore this patch explicitly configures to use the
      global RequireJS instance.
      The ext:form JavaScript is currently not written in TypeScript
      and will therefore not be automatically transformed from AND
      to ES6 when updating tsconfig.json to emit ES6 modules.
      Therefore requirejs is uses.
      This partially reverts #96326 which changed some require()
      calls to import() syntax too early.
      New npm dependencies:
       # For module-postprocessing in Gruntfile
       # This is the same parser as used for the
       # frontend polyfill es-module-shims
      yarn add --dev es-module-lexer
       # A rollup bundle for unit testing in karma is created
       # usin a karma preprocessor
      yarn remove karma-requirejs
      yarn add --dev karma-rollup-preprocessor rollup-plugin-glob-import
       # Update grunt-terser to support es2020 syntax
       # (uses terser v5 which we already depended on, but grunt v1
       # used the older v4 version)
      yarn add --dev grunt-terser@^2.0.0
      Releases: main
      Resolves: #96511
      Related: #96510
      Related: #96323
      Change-Id: Id1a6d414c1e9b2e39227d0b6ce9e79333a372349
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72637
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
  9. 19 Jan, 2022 1 commit
  10. 17 Jan, 2022 1 commit
  11. 15 Dec, 2021 1 commit
    • Stefan Bürk's avatar
      [TASK] Integrate sqlite acceptance testing · a2537436
      Stefan Bürk authored and Christian Kuhn's avatar Christian Kuhn committed
      Add support for sqlite acceptance testing to
      Run acceptance/sqlite testing with PHP 8.1 in nightly
      as a first execution implementation, which could be
      reshuffled when minimum PHP requirements have
      been decided.
      Furthermore two acceptance tests are marked as skipped
      when executed with sqlite, which should be fixed in
      dedicated patches:
      * MaintenanceCest.php->analyzeDatabaseStructureWorks()
        Skipped, as database compare is never clean and ends
        in endless loop with sqlite, when ext:indexed_search is
        installed. This is a general issue, existing at least
        since v10.4. Needs investigation and a dedicated patch.
      * UpgradeCest.php->seeUpgradeWizard()
        Skipped, as utf-8 charset upgrade wizard is not visible
        for sqlite dbms backend, thus rendering this test obsolete
        with sqlite. Needs another update wizard test and possibly
        a dedicated patch.
      Resolves: #96340
      Releases: main
      Change-Id: I74c8f1156d98a5419309e110ed761e3de21fa37a
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72446
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  12. 06 Dec, 2021 1 commit
  13. 03 Dec, 2021 1 commit
  14. 30 Nov, 2021 2 commits
  15. 17 Nov, 2021 1 commit
  16. 09 Nov, 2021 1 commit
  17. 08 Nov, 2021 1 commit
  18. 15 Oct, 2021 1 commit
  19. 11 Sep, 2021 1 commit
  20. 29 Aug, 2021 1 commit
  21. 25 Aug, 2021 1 commit
  22. 13 Aug, 2021 1 commit
  23. 06 Aug, 2021 2 commits
  24. 05 Aug, 2021 1 commit
  25. 22 Jul, 2021 1 commit
  26. 25 May, 2021 1 commit
  27. 04 May, 2021 1 commit
  28. 24 Mar, 2021 1 commit
  29. 14 Mar, 2021 1 commit
  30. 12 Mar, 2021 1 commit
  31. 01 Mar, 2021 2 commits
  32. 27 Feb, 2021 1 commit
  33. 24 Feb, 2021 2 commits
  34. 17 Feb, 2021 1 commit
  35. 15 Feb, 2021 2 commits