Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build Tooling: Support overrides to correct globals naming #21108

aduth opened this issue Mar 24, 2020 · 0 comments

Build Tooling: Support overrides to correct globals naming #21108

aduth opened this issue Mar 24, 2020 · 0 comments


Copy link

@aduth aduth commented Mar 24, 2020

Previously (some links require chat registration):

Problem: Many of the generated package names assigned to the wp do not following naming conventions, particularly in capitalization of abbreviations, classes, and @wordpress/element (React) components.

This isn't always purely a cosmetic / consistency issue either. As noted in #18722 and discussed in Slack, React will warn and/or fail outright when given a non-conforming component name.


  • wp.escapeHtml should be wp.escapeHTML (acronym)
  • wp.tokenList should be wp.TokenList (class)
  • wp.serverSideRender should be wp.ServerSideRender (React component)


Short-term: Documentation should be made consistent with current usage requirements (#18722)


  • Implement overrides support in build tooling to assign globals for specific packages in ways that cannot be programmatically inferred via the existing camelCaseDash utility.
  • Add deprecations which continue to support current usage, but log to inform developers of canonical preferred source.


As was noted at #21081 (comment), if these were treated as namespaces instead of the classes themselves, it would at least solve the second and third of the examples above, since the named exports of a package are not transformed.

  • wp.tokenList could be wp.tokenList.TokenList
  • wp.serverSideRender could be wp.serverSideRender.ServerSideRender



  • Verbose
  • Arguably unnecessary, if the exported member of these modules truly represents the semantics associated with a default export
  • Doesn't address all of the issues (escapeHtml)
    • Would probably still need a solution like considered in "Proposal"
  • Backwards-compatibility implications by changing the public API of published packages

Additional Notes:

This globals assignment occurs both in Gutenberg and as well in WordPress core:

A solution should consider to apply in both places.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.