# Description of Changes
This PR refactors the frontend icon system to remove reliance on
@mui/icons-material and the Google Material Symbols webfont.
🔄 Changes
Introduced a new LocalIcon component powered by Iconify.
Added scripts/generate-icons.js to:
Scan the codebase for used icons.
Extract only required Material Symbols from
@iconify-json/material-symbols.
Generate a minimized JSON bundle and TypeScript types.
Updated .gitignore to exclude generated icon files.
Replaced all <span className="material-symbols-rounded"> and MUI icon
imports with <LocalIcon> usage.
Removed material-symbols CSS import and related font dependency.
Updated tsconfig.json to support JSON imports.
Added prebuild/predev hooks to auto-generate the icons.
✅ Benefits
No more 5MB+ Google webfont download → reduces initial page load size.
Smaller install footprint → no giant @mui/icons-material dependency.
Only ships the icons we actually use, cutting bundle size further.
Type-safe icons via auto-generated MaterialSymbolIcon union type.
Note most MUI not included in this update since they are low priority
due to small SVG sizing (don't grab whole bundle)
---
## Checklist
### General
- [ ] I have read the [Contribution
Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md)
- [ ] I have read the [Stirling-PDF Developer
Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md)
(if applicable)
- [ ] I have read the [How to add new languages to
Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md)
(if applicable)
- [ ] I have performed a self-review of my own code
- [ ] My changes generate no new warnings
### Documentation
- [ ] I have updated relevant docs on [Stirling-PDF's doc
repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/)
(if functionality has heavily changed)
- [ ] I have read the section [Add New Translation
Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags)
(for new translation tags only)
### UI Changes (if applicable)
- [ ] Screenshots or videos demonstrating the UI changes are attached
(e.g., as comments or direct attachments in the PR)
### Testing (if applicable)
- [ ] I have tested my changes locally. Refer to the [Testing
Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md#6-testing)
for more details.
---------
Co-authored-by: a <a>
* automate feature
* Moved all providers to app level to simplify homepage
* Circular dependency fixes
* You will see that now toolRegistry gets a tool config and a tool
settings object. These enable automate to run the tools using as much
static code as possible.
---------
Co-authored-by: Connor Yoh <connor@stirlingpdf.com>
# Description of Changes
Because we used string typing for IDs and names, it was really easy to
make mistakes where variables named like `subcategory` would be stored
as an ID in one file, but then read assuming it's a name in another
file. This PR changes the code to consistently use enum cases when
referring to IDs of categories, subcategories, and tools (at least in as
many places as I can find them, ~I had to add a `ToolId` enum for this
work~ I originally added a `ToolId` type for this work, but it caused
too many issues when merging with #4222 so I've pulled it back out for
now).
Making that change made it obvious where we were inconsistently passing
IDs and reading them as names etc. allowing me to fix rendering issues
in the All Tools pane, where the subcategory IDs were being rendered
directly (instead of being translated) or where IDs were being
translated into names, but were then being re-translated, causing
warnings in the log.
