--- tags: build --- # Build wish list List of build-related work items that we'd like to address eventually. Feel free to add things. :christmas_tree: ## Short-term - Size auditor speed improvements - Split test-bundles into 2+ jobs which can run in parallel on multiple agents - If the final lightrail job can't handle multiple inputs, we can add an "aggregate" job which waits for the main jobs to finish and combines their results - Possibly change to "self-host ubuntu" pool for all but the lightrail job? (I think that's the only Windows-dependent part.) - Downside: we'd lose all automatic Windows validation of build changes - Setting up a faster custom Windows pool for just this job is not a good option due to the amount of work required to set up and maintain - Contributor experience improvements - Better documentation of build process and repo layout! - Better experience for adding new packages (fix create-package to handle more scenarios) - Better "migration" experience for build workflow: if the workflow or tooling changes significantly, make the old path fail nicely, with instructions for what to do now - "help" command and/or option - Getting better insight into why builds failed - Combining build/test/lint into one step was not so helpful for analytics... Can we split them out and re-enable some form of caching, at least locally between steps? (Recent security guidance about not exposing even "harmless" secrets does make it seem like we shouldn't be exposing blob storage tokens for `backfill` cloud cache. "It'll probably be fine except on the off chance that someone does decide to target us" is not a very good rationale.) - Look into using [logging commands](https://docs.microsoft.com/en-us/azure/devops/pipelines/scripts/logging-commands?view=azure-devops&tabs=bash) or other ADO stuff to log more specific failure reasons - TS upgrade + project references - Need to look into generating backwards-compatible .d.ts (possibly with typesVersions) ## Longer-term or uncategorized - Get rid of separate build for /fluentui packages - Config extension/de-duplication? -- this is getting worse as we add more packages - tsconfig extension (easy) - jest? (anything else we should add to shared config? this one isn't as bad) - webpack: share more parts of config (or add options) if appropriate - Type check once - Speed up task registration: don't parse deps you don't need - The main thing slowing down task registration with both `just` and `gulp` is that - do you get the type checking when you async import()? can node do that? - Run prettier in CI (at least validate, ideally also commit?) - Enable ESLint for build scripts - Project references and incremental builds working properly everywhere - Faster react-icons build - Move away from size auditor - Switch release pipelines to use YAML? - Define npmignore *once* in a shared location and copy to individual packages pre-publish (still allowing overrides/additions per-package, probably with special comments to control merging behavior). Or at least add a script for syncing it and writing all the change files. - v7 website build (copied from [v8 release logistics](/PR2qTS_1S3CYU8ungN3Dsw?edit) since it's not essential for the release) - Look into making same release pipeline tasks work across 5/6/7/master (task group with variable?) - Look into driving version switcher from manifest or something (to avoid needing manual updates across multiple files and branches) - hackathon: chrome extension for editing markdown on github (syntax highlighting + live preview) - Instead of checking in .npmignore and .npmrc, generate them in a pre-publish step. That way they all stay in sync without having to do giant find/replace changes for all updates. (In cases where individual packages need different settings, they could check in a file with just the overrides and the generation step would concatenate them.)