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.
Publishing npm packages
@gziolo announced that we published to npm new versions of all WordPress packages.
@gziolo added that we didn’t publish to npm in the last two months, although we could do it given that 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/ release happens every other week.
@gziolo asked for thoughts on how we can improve the process overall, and maybe automate it.
People noticed that the current process involves lots of manual work.
Some options were discussed, @gziolo noted that he does not think we can publish to npm from CI since we require all accounts to use 2FA.
@nerrad suggested we can do an iteration on the automation scripts @youknowriad build andding something like `commander deploy Launching code from a local development environment to the production web server, so that it's available to visitors.:trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.`.
@jorgefilipecosta noted that an automation tool will face a problem when merging Gutenberg PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher changes to core Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
@youknowriad agreed and added that the PHP could never be automated. Both repositories have different PHP setups/requirements (one is a 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 on top of the other). But noted PHP is the small part of the work, and a helper tool could compare versions and say, we have these PHP changes, don’t forget to backport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. them.
In continuation of the PHP code updates conversation, @omarreiss added that:
Normally I would solve a problem like this by treating the Gutenberg PHP as a dependency of WordPress core. We could install that and keep that up to date by using composer. There is a ticket Created for both bug reports and feature development on the bug tracker. open for managing external PHP dependencies with the composer, but it’s not moving very fast, see https://core.trac.wordpress.org/ticket/47256. If that were the case, we could register an alternative initializer/autoloader when Gutenberg is active, and we would be done. The only problem is that the PHP in Gutenberg isn’t well isolated. To really solve this problem, the PHP in Gutenberg needs to start behaving like a more clean dependency, and we should centralize its initialization. This would require some refactoring. I wouldn’t mind exploring this approach, but I’d like some blessings on the direction from people like @pento and @jorbin first.
@youknowriad noted that @omarreiss suggestion means re-architecture WordPress to be built using PHP modules (same as we do with JS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.). @omarreiss agreed and said that was the reason why he does not want to explore further without some openness to the direction.
Help build an automation tool
@gziolo asked if we have someone willing to explore how we can automate as much as possible to make the process on WordPress core side less time-consuming and error-prone?
@dsifford said that he does not want to get distracted from the other work he is currently doing (jsdoc improvements), but we can consider him a fallback in case no one takes up this task.
If this task is something that interests you, and you want to expand knowledge about scripting and automation, please tell us about your interest in the comments.
Gutenberg Examples repository
@gziolo opened the topic by saying that we still maintain a repository with Gutenberg examples (https://github.com/WordPress/gutenberg-examples), and asked:
What’s the process like for such repositories with merging changes? I have PR opened, and I have no idea what to do next: https://github.com/WordPress/gutenberg-examples/pull/83.
@netweb answered:
What I typically see is another Gutenberg core dev will to a drive-by review, approve and merge. So, nothing official.
The conversation continued and aborded specific subjects related to the PR @gziolo referred.
@gziolo concluded that although this repository isn’t as popular as others, we should still go through review/approve process as it’s useful.
Other subjects
@dsifford asked for reviews on PR https://github.com/WordPress/gutenberg/pull/16869 – “Add eslint-plugin-jsdoc for better JSDoc linting“.
People talked a little bit about that PR and chat participants provided some feedback.
Meanwhile, after the chat, the PR got a review, was approved and merged.
#core-js, #javascript, #meeting, #summary
