Local Environment: Follow Semantic Versioning and include release notes when publishing #31
Comments
|
Using separate versions for each package in a monorepo gets very messy very quickly, as outlined in WordPress/gutenberg#46693. It is very convenient to advance versions of all packages in a monorepo together, even if that means an occasional version bump that has no merit on its own. It is a trade-off, but one with an overwhelming amount of benefits – see the discussion and this comment from @noahtallen and this comment from @jsnajdr. I'm not against semantic versioning in wp-now, but I'd consider a separate repository – even if it would contain just a shell package for publishing purposes. |
|
We can wait and see what sort of feedback we get. |
|
I think that mostly matters when you have a ton of packages which all depend on each other, and you have to install a lot of them in the same project. (Which definitely describes most of the editor packages!) But something like It just gets so easy have implicit dependencies. If you need to install both package A and B, and A starts relying on a new feature in package B -- but at the same time, package B doesn't work if there are two copies of it at runtime -- things will break. Then you do need to update both simultaneously or you'll break things. That relationship is hard to encode with versioning, but it's more straightforward to manage when it's just "ahh everything needs to on the same version" I have no clue how that applies to wp-now though! |
|
Thank you @noahtallen! The VS code extension depends on wp-now and I anticipate more such packages. There are good reasons to import both wp-now and other packages from this repo - e.g. TypeScript types for Blueprints and PHP. Here's the current project graph, to visualise how hard it would be to maintaining separate versions of interdependent packages: 
How about splitting
|
|
Oh, that reminds me about executables and npx. For example, if I wanted to run wp-env through npx without installing it, you'd have to do |
I'd be fine with this approach (as long as it isn't a total mess)
How do we do this if https://www.npmjs.com/package/wp-now already exists? |
🙃 |
…s#31) ## What problem does this PR solve? Adds support for running WASM WordPress in multiple browser tabs and solves WordPress#9. All WordPress requests are routed through a single service worker shared between all browser tabs. The request lifecycle looks as follows: 1. A request originates in a specific tab 2. A service worker intercepts it and requests the same tab to pass it to its WASM WordPress instance 3. The tab renders it and sends the response to the service worker 4. The service worker responds to the intercepted HTTP request using the WordPress-generated response 5. The original tab receives the WordPress-generated response and displays it to the user It's a back-and-forth conversation between a specific browser tab and the service worker. Unfortunately, Service workers communicate with tabs using a `BroadcastChannel` – it's a messaging strategy that routes every message to every listener. As a result, each WordPress request was rendered in every tab, often causing unexpected behaviors. ## How does this PR propose to solve it? This PR introduces a concept of WordPress `scope` and enables the service worker to post BroadcastChannel messages scoped to specific listeners. Scoping a WordPress instance means installing it at a unique pathname starting with `/scope:<unique number>`. For example: * In an unscoped WordPress instance, `/wp-login.php` would be available at `http://localhost:8778/wp-login.php` * In a scoped WordPress instance, `/wp-login.php` would be available at `http://localhost:8778/scope:96253/wp-login.php` The scope number is a random and unique number generated by a specific browser tab. The service worker is aware of this concept and will use any `/scope:` found in the request URL to tag all the related `BroadcastChannel` communication. The WASM workers running in specific browser tabs will then ignore all the `BroadcastChannel` communication with an unfamiliar `scope` attached. ## Alternatives considered * Using the `scope` feature of ServiceWorker – it led to multiple worker registrations and was hard to reason about. * Loading Workers from a tab-specific unique URL, e.g. `sw.js?tab_id=432` or `sw-1.js` – it led to the same problems as relying on the `scope` feature. * Match the request with its originating tab in the ServiceWorker – There's not enough information available. The worker can't figure out the top-level client ID from a request originating in an iframe, and the top-level client wouldn't be able to tell whether the request originated in its browsing context. * Scoping WordPress instance by a domain, e.g. `w87953.localhost` – it would require setting up a catch-all DNS domain to even use this project. That's a steep barrier of entry. * Displaying an error in other browser tabs – it would be a large and unnecessary limitation. ## How to test? Run `npm run dev` and open the WASM WordPress page in a few different browser tabs. Log in, create pages, play with it, and confirm that each tab behaves as expected. Specifically: * No tab should unexpectedly log you in or out * No pages and changes should leak between the browser tabs ## Follow-up work * If a use-case arises, a tab could use `sessionStorage` to preserve the scope across page reloads.
Due to how the repository is set up, all packages are published at the same time with the same version number:
To the end user of
wp-now, the package version number will seem somewhat random. It may receive a major version change when some other package receives a breaking change.Previously WordPress/wordpress-playground#340 (comment)
Done is:
The text was updated successfully, but these errors were encountered: