Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.
This week we discussed WordPress packages and how to optimize their distribution using npm. As of today, Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ is built of 41 packages where each of them can be used independently by every plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme developer in their projects.
Duplication concerns over independent versioning
Problem: An issue was raised about our independent versioning of packages, and how this can lead to duplication which, for packages like data which behave as a singleton, can result in some pretty undesirable outcomes. Related comments on GitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/:
- This is not specific to
@wordpress/data, and could affect anything which behaves in a global / singleton fashion:
- The issue is mitigated but not eliminated by moving away from Lerna independent versioning (toward fixed versioning) because the chance for differing versions still exists.
- This shouldn’t be an issue in WordPress context at all. This seems to be an issue for external apps which consume WordPress packages directly from npm.
Decision: Avoid “globals” behavior, where a consumer must define and operate with its own registry (specific to
How required built-ins should be polyfilled
Problem: The current npm packages that being built for Gutenberg polyfill usage of some browser features that are not available on older browsers. This polyfill is global and affects any client who uses WordPress npm packages. This is unexpected and can alter the runtime environment in surprising ways. More details in the related issue.
corejs flag should be set to
false when generating distribution version for packages and set to
2 when bundling with Webpack. In addition, we should inform developers consuming WordPress packages to install proper polyfills on their own.
Guidelines for releases
Proposal: We have a documentation proposal to improve guidelines for creating, managing and publishing packages.
Observations: The versioning recommendations are very oriented toward deprecations which seems to be the right approach.
Action item: Add section about managing changelogs based on the discussion from last week.