Feature Flags: Update package to support aliases 🏖️

[tay1orjones]

In https://github.com/carbon-design-system/carbon/pull/15964 we outlined the approach we'd like to take in our next major to ship breaking changes behind feature flags in the current/v11.

As part of this, flags can "graduate" from experimental status and become committed to a release. This is done by renaming the flag:

enable-tile-contrast -> enable-v12-tile-contrast

Ideally the feature flag package would support this rename workflow so it would be seamless from an authoring perspective and from a user perspective:

• New flags and old flags can be linked or associated in some way and have a single root definition of if they're enabled or not.
• A new flag can be added without having to modify any usages of the old flag(s) within @carbon/react
• Both flags continue to work seamlessly for consumers, but they get a warning if they use an old flag that points them to the new flag name.

I think we could accomplish this by adding support for the concept of flag "aliases":

• Entries in feature-flags.yml could include a new aliases property that would be an array of strings.
• A v12 flag would be added and have an aliases entry of the old experimental flag name
• Feature flag code would be updated to export/output the alias as a feature flag in the generated files
• checkForFlag(), enabled(), disabled(), etc would need updated to check against aliases
• I think the warning for the old name could emit from checkForFlag()

Without this work we'll have to have duplicate flag definitions and double check both flags within @carbon/react, example. It's prone to error and requires extra maintenance overhead. This would also cover us for anytime a flag name needs to change due to misspelling, change in scope, or any other reason.

---

Also we decided in https://github.com/carbon-design-system/carbon/pull/15964 to move away from the enable-experimental-* naming convention.

• [ ] All flags currently named enable-experimental-* should have a new primary alias of enable-* instead.
• [ ] Storybook and all other documentation should be updated to no longer use enable-experimental-* names

---

Additional related concerns:

• Users should be prompted to update their usages of old flag names to the new flag names. We could automate this with a special codemod.
• Users should be prompted to remove flags they've set to true that are "on by default" as they're no longer needed - or maybe we could just notify them that these can likely be removed
• It would be nice if we could use this same warning/prompting system to inform users of an upcoming major release and suggest they begin incorporating enable-v12-* flags into their project as soon as possible to get a head start on things. Maybe this could be done emitted from the <FeatureFlag> component?

[github-actions[bot]]

Thank you for submitting a feature request. Your proposal is open and will soon be triaged by the Carbon team.

If your proposal is accepted and the Carbon team has bandwidth they will take on the issue, or else request you or other volunteers from the community to work on this issue.

[sstrubberg]

I'm totally down for this but can we get some examples of how it might be used in relation to the next major? I guess I'm sorta wondering if this is a must have vs. a nice to have for v12.