@ms-cloudpack/data-bus 0.5.0 → 0.5.1

package/README.md

@@ -1,6 +1,6 @@
 # @ms-cloudpack/data-bus
 
-Provides a general api for subscribing/unsubscribing from data and defining providers to that data.
+Provides a general API for subscribing/unsubscribing from data and defining providers to that data.
 
 Examples of usage:
 
@@ -11,7 +11,7 @@ Examples of usage:
 
 ### Initialization
 
-A data bus can be created using the `createDataBus` api:
+A data bus can be created using the `createDataBus` API:
 
 ```js
 import { createDataBus } from '@ms-cloudpack/data-bus';
@@ -106,19 +106,19 @@ const currentValue = bus.getData(itemCountPath);
 
 ## Motivation
 
-Cloudpack runs a bundle service which is accessed to retrieve esm package bundles on the fly. As dependencies are requested, the service produces assets into a cache folder.
+Cloudpack runs a bundle server which is accessed to generate and retrieve ESM package bundles on the fly. As dependencies are requested, the server produces assets into a cache folder.
 
 Many consumers may request the same bundle at the same time. This implies 1. We need to dedupe redundant requests, and 2. We need to reuse the output to fulfill future requests.
 
-In the original implementation, requests to the same resource would first check cache for results, find it missing, and start bundling by calling an imperative api like `async bundle(options: Options): Result`. This would write to a cache location, which would then fulfill future requests. But this left race conditions because we weren't deduping in-flight requests, nor were we re-populating bundles that changed inputs slightly. This led to the question: what kind of architecture would we need to essentially dedupe redundant requests, and provide a general architecture for caching content?
+In the original implementation, requests to the same resource would first check cache for results, find it missing, and start bundling by calling an imperative API like `async bundle(options: Options): Result`. This would write to a cache location, which would then fulfill future requests. But this left race conditions because we weren't deduping in-flight requests, nor were we re-populating bundles that changed inputs slightly. This led to the question: what kind of architecture would we need to essentially dedupe redundant requests, and provide a general architecture for caching content?
 
 We ran into other similar scenarios:
 
-- 1 or more Dashboard pages need a list of packages installed. When the dependencies change, the page should be notified so that it can update ui.
-- 1 or more Dashboard instances needs metadata for a package. Metadata access is expensive, so we should dedupe requests and ensure the results go to all subscribers.
+- One or more dashboard pages need a list of packages installed. When the dependencies change, the page should be notified so that it can update UI.
+- One or more dashboard instances needs metadata for a package. Metadata access is expensive, so we should dedupe requests and ensure the results go to all subscribers.
 - Dashboards need to show the current build state for a session. Green for pass, red for fail, and should render errors when clicked. This also requires live updates, and may have multiple subscribers.
 
-This led to the idea of a data-bus; a general mediator for managing subscriptions and informing providers when results are available or have changed.
+This led to the idea of a data bus: a general mediator for managing subscriptions and informing providers when results are available or have changed.
 
 ## Future considerations
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ms-cloudpack/data-bus",
-  "version": "0.5.0",
+  "version": "0.5.1",
   "description": "A data bus implementation.",
   "license": "MIT",
   "type": "module",
@@ -24,7 +24,7 @@
     "test": "cloudpack-scripts test"
   },
   "dependencies": {
-    "zod": "^3.25.0"
+    "zod": "^4.0.0"
   },
   "devDependencies": {
     "@ms-cloudpack/eslint-plugin-internal": "^0.0.1",