Change Details

=Documentation on wiki https://m.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture#Automate_asset_bundling =What Use a Node.js based bundler (webpack) to compile the JavaScript files into different entry points automatically based only on source code import statements. These bundled files will then be given to ResourceLoader for serving. This approach is the same one taken in Extension:Popups (Page Previews), which has proven to be an effective strategy. We will also use UglifyJS for minifying our JavaScript files for production, which should give us approximately 25% savings on file sizes for the mobile website. =Progress There are ~80 JavaScript files in MobileFrontend, in 58 modules. 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. =AC [] Whe have documented the LOC we have, and the client bundle sizes served, for further analysis after the project ends [] 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`) [] The build process is configured to use uglifyJS when outputting production assets [] The build assets are properly configured to be served by ResourceLoader from MediaWiki [] The sources in `resources/` have been migrated to `src/`, using EcmaScript modules syntax, and babel for transpiration to es5 [] There is a linting step for verifying that the production bundles in `resources/dist` are es5 compliant [] 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

=Documentation on wiki https://m.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture#Automate_asset_bundling =What Use a Node.js based bundler (webpack) to compile the JavaScript files into different entry points automatically based only on source code import statements. These bundled files will then be given to ResourceLoader for serving. This approach is the same one taken in Extension:Popups (Page Previews), which has proven to be an effective strategy. We will also use UglifyJS for minifying our JavaScript files for production, which should give us approximately 25% savings on file sizes for the mobile website. =Progress There are ~80 JavaScript files in MobileFrontend, in 58 modules. 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. =Measuring success 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 =AC [] 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 [] 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`) [] The build process is configured to use uglifyJS when outputting production assets [] The build assets are properly configured to be served by ResourceLoader from MediaWiki [] The sources in `resources/` have been migrated to `src/`, using EcmaScript modules syntax, and babel for transpiration to es5 [] There is a linting step for verifying that the production bundles in `resources/dist` are es5 compliant [] 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

=Documentation on wiki https://m.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture#Automate_asset_bundling =What Use a Node.js based bundler (webpack) to compile the JavaScript files into different entry points automatically based only on source code import statements. These bundled files will then be given to ResourceLoader for serving. This approach is the same one taken in Extension:Popups (Page Previews), which has proven to be an effective strategy. We will also use UglifyJS for minifying our JavaScript files for production, which should give us approximately 25% savings on file sizes for the mobile website. =Progress There are ~80 JavaScript files in MobileFrontend, in 58 modules. 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. =Measuring success 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 =AC [] WhWe have documented the LOC we havee client bundle sizes served, and the client bundle sizes servedthe amount of manual configuration for scripts in `.ResourceModules` extension.json, for further analysis after the project ends [] 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`) [] The build process is configured to use uglifyJS when outputting production assets [] The build assets are properly configured to be served by ResourceLoader from MediaWiki [] The sources in `resources/` have been migrated to `src/`, using EcmaScript modules syntax, and babel for transpiration to es5 [] There is a linting step for verifying that the production bundles in `resources/dist` are es5 compliant [] 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