Documentation on wiki
This approach is the same one taken in Extension:Popups (Page Previews), which has proven to be an effective strategy.
We will go module by module, file by file, migrating the file to the src/ folder like in Extension:Popups, adapting the imports/exports, and moving the QUnit test files to node-qunit if possible/easy.
Progress can be measured by looking at the amount of files and lines of code migrated to the src/ folder.
We will be successful if:
- There is a reduction in the size of the JS assets served to clients due to better minimization
- There is a big reduction on the amount of manual JSON configuration needed for sorting the JS files (.ResourceModules on extension.json)
- The performance of MediaWiki locally on development is better due to the decreased load on ResourceLoader
- We have documented the client bundle sizes served, the amount of manual configuration for scripts in .ResourceModules extension.json, for further analysis after the project ends (see T165036 for an example which includes bundlesize checks, Webpack performance hints, and ADR and blog post docs)
- There is a build setup with npm scripts start and build that bundles the assets and outputs them to resources/dist
- CI checks on every commit that the built assets committed in the repo are up to date with the committed sources (like in Extension:Popups-an experiment is underway to _not_ version artifacts)
- The build process is configured to use UglifyJS when outputting production assets
- The development build process includes a script to monitor and automatically rebuild debug assets (see Popups)
- The build assets are properly configured to be served by ResourceLoader from MediaWiki (see Popups)
- The sources in resources/ have been migrated to src/, using EcmaScript modules syntax, and babel for transpilation to ES5
- There is a linting step for verifying that the production bundles in resources/dist are ES5 compliant (see Popup's ES5 ESLint config or this eslint-plugin-compat spike)
- The built assets are split automatically to have common modules of bundles based on the entry points, and configured correctly to be performant for our most common cases
- We measure our success metrics after the work is finished and compare and report with the initial metrics