feat: Add NonDeprecatedIcons map with 2,089 active icons

[Mohamed-Nagdy]

• Exclude deprecated icons from mapping
• Provide string-based icon access
• Auto-generated from source file

[saropa]

Hi,

I find the AIs are quite out of date when it comes to FontAwesome and so the deprecation warnings are very useful to migrate code. Wouldn't this change remove that feature?

(Also, aren't unused icons tree-shaken at build time?)

[Mohamed-Nagdy]

Hi,
Thank you for the feedback! You raise excellent points. Let me clarify the purpose and scope of this addition:
Regarding deprecation warnings:
This change doesn't remove any existing deprecation features - all the original deprecated icons and their warnings remain intact in the main FontAwesomeIcons class. This is purely an additive feature that provides a convenience map for developers who specifically need to work with only non-deprecated icons.
Use cases for this addition:
Dynamic icon selection: When building icon pickers or UI builders where users select icons by name
Configuration-driven UIs: Where icon names come from JSON/config files
Documentation/tooling: For generating lists of available icons without deprecated ones
Migration assistance: Ironically, this actually helps with migration by clearly identifying which icons are safe to use
Tree-shaking consideration:
You're absolutely right about tree-shaking! This map references the same FontAwesomeIcons constants, so unused icons will still be tree-shaken at build time. The map itself only contains references, not duplicate icon data.
Alternative approach:
If you prefer, I could modify this to be a separate utility package or move it to an example/tool directory rather than the main library. The core functionality would remain unchanged.
The goal is to enhance the developer experience while preserving all existing functionality and warnings. What are your thoughts on this approach?

[saropa]

Hi,

We also have use cases when tree-shaking is excluding and all icons are needed - e.g. on the web, or when doing dynamic name look-ups like you describe.

Our workflow for mobile is to resolve all deprecation notices before PR and automatically tree-shake at build to minimize deployment size.

I think a separate utility/script like you suggest would support both.