@flamework-experimental/networking 2.0.0-alpha.2 → 2.0.0-alpha.3

package/README.md

@@ -1,15 +1,17 @@
 # Flamework
 
-Flamework is an extensible framework for roblox-ts designed around portable, isolated and testable modules.
+Flamework is an extensible framework for roblox-ts. It is built around modules that are portable,
+isolated and easy to test.
 
 ## Documentation
 
-**[docs/](docs/README.md)** -- start there. A ten-part guide that builds up from a working entry
-point to plugins and project layout, plus reference material:
+Start with **[docs/](docs/README.md)**. It holds a twelve-part guide, which starts from a working
+entry point and builds up to plugins, project layout, scopes and testing. It also holds reference
+material:
 
 | | |
 |---|---|
-| [Guide](docs/README.md#guide) | Getting started, modules, providers, lifecycle events, components, networking, macros, plugins, project structure, migrating from v1. |
+| [Guide](docs/README.md#guide) | Getting started, modules, providers, lifecycle events, components, networking, macros, plugins, project structure, migrating from v1, scopes, testing in the place. |
 | [Internals](docs/reference/internals.md) | What the transformer does to your code and what the runtime does with the result. |
 | [Transformer plugins](docs/reference/transformer-plugins.md) | Adding macro types of your own. |
 
@@ -37,36 +39,36 @@ bun run test:place     # the in-place suite in Roblox Studio (tests/place); need
 | `packages/core` | Modules, dependency injection, plugins and lifecycle events |
 | `packages/components` | CollectionService components, built on the core plugin system |
 | `packages/networking` | Remote events and functions |
-| `packages/testing` | In-place tests: sections, cleanup, a bindable and a remote to run them, a cloud entry; and `flamework-test`, the CLI that runs them in Roblox Studio on this machine or through Open Cloud (`cli/`) |
+| `packages/testing` | Tests that run inside a place: sections, cleanup, a bindable and a remote that run them, and a cloud entry point. Also `flamework-test` (`cli/`), the CLI that runs them in Roblox Studio on this machine or through Open Cloud |
 | `packages/transformer` | The roblox-ts transformer |
 | `packages/transformer-plugin` | Public API for writing transformer plugins |
-| `packages/specs` | Runtime specs, compiled by `rbxtsc` and executed under Lune |
+| `packages/specs` | Runtime specs, built by `rbxtsc` and run under Lune |
 
 ### Tests
 
-Two suites, both run by `bun run test`:
-
-- **Transformer tests** (`bun run test:unit`) compile a fixture project with the real `rbxtsc` and
-  assert on the emitted Luau — guard generation, identifiers, nested macros and the plugin system.
-- **Runtime specs** (`bun run test:runtime`) execute compiled `@flamework-experimental/core`, `components` and
-  `networking` under Lune using the harness in [`tests/runtime`](tests/runtime), which models
-  roblox-ts's `TS.import` tree over the filesystem and stubs the Roblox API surface Flamework
-  touches (Instances, attributes, CollectionService, RemoteEvents, Players, signals, `task`,
-  `Enum`, and a `Heartbeat` pump so `Promise.delay` -- and therefore request timeouts -- runs).
-  They cover dependency injection, modules, hooks and the per-frame lifecycle events, component
-  construction, dependencies and streaming, and both halves of networking: events, functions,
-  middleware and the generated guards.
-
-  They run twice, once as `Server` and once as `Client`, because realm-dependent code paths --
-  `@Provider`'s metadata, component streaming, and the client/server halves of networking -- differ
-  between them. Where a spec asserts something realm-specific, running it from both sides is what
-  proves the two agree: a function receives on `$name` and sends on `@name` from the server and the
-  mirror image from the client, so the pair of runs pins the wire format down from both ends.
-
-Specs live in [`packages/specs`](packages/specs) and are compiled by `rbxtsc` like any other
-Flamework consumer, so they exercise the transformer and the runtime together.
-
-A third suite runs against the real engine and is left out of `bun run test`: the
-[test place](tests/place/README.md), a small game linked to the packages' builds, whose
-`@flamework-experimental/testing` sections `bun run test:place` runs in Roblox Studio, both realms,
-under four Rojo projects (see [Testing in Roblox Studio](docs/testing/studio.md)).
+`bun run test` runs two suites:
+
+- **Transformer tests** (`bun run test:unit`) build a fixture project with the real `rbxtsc` and
+  check the Luau it emits: guard generation, identifiers, nested macros and the plugin system.
+- **Runtime specs** (`bun run test:runtime`) run the built `@flamework-experimental/core`,
+  `components` and `networking` packages under Lune. The harness in [`tests/runtime`](tests/runtime)
+  models roblox-ts's `TS.import` tree over the filesystem. It also stubs the parts of the Roblox API
+  that Flamework uses: Instances, attributes, CollectionService, RemoteEvents, Players, signals,
+  `task`, `Enum`, and a `Heartbeat` pump so that `Promise.delay` runs (and with it, request
+  timeouts). The specs cover dependency injection, modules, hooks and the per-frame lifecycle
+  events; component construction, dependencies and streaming; and both halves of networking:
+  events, functions, middleware and the generated guards.
+
+  The specs run twice, once as `Server` and once as `Client`, because some code paths depend on the
+  realm: `@Provider`'s metadata, component streaming, and the client and server halves of
+  networking. Running a realm-specific spec from both sides proves that the two sides agree. For
+  example, from the server a function receives on `$name` and sends on `@name`, and from the client
+  it does the reverse, so the two runs pin down the wire format from both ends.
+
+Specs live in [`packages/specs`](packages/specs). `rbxtsc` builds them like any other project that
+uses Flamework, so they test the transformer and the runtime together.
+
+A third suite runs against the real engine, and `bun run test` leaves it out. It lives in the
+[test place](tests/place/README.md), a small game linked to the packages' builds.
+`bun run test:place` runs its `@flamework-experimental/testing` sections in Roblox Studio, on both
+realms, under four Rojo projects (see [Testing in Roblox Studio](docs/testing/studio.md)).

package/flamework.build

@@ -1,6 +1,6 @@
 {
 	"version": 1,
-	"flameworkVersion": "2.0.0-alpha.3",
+	"flameworkVersion": "2.0.0-alpha.4",
 	"identifiers": {},
 	"idGenerationMode": "full",
 	"identifierPrefix": "$n"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flamework-experimental/networking",
-  "version": "2.0.0-alpha.2",
+  "version": "2.0.0-alpha.3",
   "main": "out/init.luau",
   "types": "out/index.d.ts",
   "scripts": {
@@ -15,7 +15,7 @@
     "access": "public"
   },
   "peerDependencies": {
-    "@flamework-experimental/core": "*"
+    "@flamework-experimental/core": "^2.0.0-alpha.0"
   },
   "devDependencies": {
     "@flamework-experimental/core": "2.0.0-alpha.2",