Below is a of the discussion from this week’s JavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. chat (agenda, Slack Transcript)
Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.
Agenda: Unstable APIs
Slack Conversation
There was a conversation recently 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/ where it became evident that marking an API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. as unstable is not sufficient enough in its own right to scare people away from using them (and subsequently being frustrated that they’re not documented).
This was a lively discussion around whether there are programmatic ways to make it harder for people to use things marked __unstable .
Due to the fact there aren’t a lot of occurrences of __unstable in the code currently, the general consensus seems to be that if people are using __unstable that is a risk they are taking and there shouldn’t be worry about removing it because it’s purpose is clear.
However, this could be revisited in the future if we see usage pick up and ideas mentioned in the meeting may be explored further then.
So readers, TAKE NOTE – use anything prefixed with __unstable at your own risk. Expect your code to break in the future if you are implementing it!
Agenda: New ESLint Rule
Slack Conversation|Related Github Issue
A new rule was introduced, no-unused-vars-before-return
Agenda: Yarn future (fyi)
Slack Conversation | Related Yarn Github Issue | Related Earlier Slack Discussion
Some discussion around some potential benefits this roadmap could have should yarn be adopted for WordPress builds in the future:
- Yarn as an API (which could open the door to controlling some things from a GUI). This could allow for building easier developer tools.
- Yarn as a package manager platform – which means there could potentially be one package manager for both npm and packagist.
- Improvements to mono-repo management (in terms of managing both js and php packages)
This was mostly presented just to get on everyone’s radar. There’s nothing actionable at the moment.
As an aside: if you become aware of interesting developments in the javascript world, please do include them as fyi’s in #core-js meeting agendas!
Agenda: Package alignment with core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
Slack Conversation | Related Make Post
@desrosj presented how looking at this trac ticket got him thinking about how we can better align package versions with Core to prevent issues like what popped up there.
Summary of what could become a proposal:
- In simplest form, change version constraints in the
package.json - When a major WordPress version is released (say 5.1), the versions of each package become restricted to only minor and patch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. updates to
@wordpress/* packages and dependencies. This allows someone to run npm update when preparing a WP minor release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. (5.1.1) for beta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.. - When a new major WordPress version is prepared, a new major version of the 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/ packages would be released (if necessary), and WP core would be updated to use that new version. This next WP version (5.2) would be locked to that next version’s patch and minor updates only.
- From a process standpoint, this would require the Gutenberg branches to somewhat match core’s. There would need to be a 5.1 branch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". after that is released. Instead of cherry picking changes by using package versions, we could only back port the appropriate changes to that branch and publish the X.X or X.X.X versions of those NPM packages
The difference between what is currently being done and what is being proposed is that whenever there is a major release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. of WordPress, all versions of packages will be bumped with major or minor (as opposed to patch).
One reason this was brought up is concern for how security patches etc will be back-ported to earlier WordPress versions in the future
Next Steps
- Tighten up semver in
@wordpress/* packages which means enforcing proper usage of CHANGELOG.md and properly differentiating between minors and patches. (No owner currently) - Explore more automation of the package management/updates in WordPress core (No owner currently)
- This does need revisited in future meetings. Work should be done on identifying clearly the problems needing solved.
#javascript
