Repository navigation
chore: Make Workspace and WorkerJavaScriptBackend stable - #241
Conversation
馃 Changeset detectedLatest commit: e93d3ba The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| | [03. Filesystem Schema](./03_filesystem_schema.md) | Stable | SQLite schema backing the virtual filesystem. | | ||
| | [04. Filesystem Interface](./04_filesystem_interface.md) | Stable | `Workspace.fs` API: `readFile`, `writeFile`, `mkdir`, `grep`, etc. | | ||
| | [05. Runtime Interface](./05_runtime_interface.md) | Stable | `Workspace.runtime.exec/getExec/killExec/disposeExec` and backend routing. | | ||
| | [06. Mount Interface](./06_mount_interface.md) | Stable | Pre-filling paths from R2, Artifacts, GitHub, and custom sources. **(not yet implemented)** | |
There was a problem hiding this comment.
馃攳 Stable label covers planned mount APIs
The mount guide describes planned lazy mounts and write-back, while Mount supports only eager mounts. Labeling the whole guide stable obscures which examples callers can use today.
Was this helpful? React with 馃憤 or 馃憥 to provide feedback.
| | [10. Project Layout](./10_project_layout.md) | Reference | Source tree of this package and how the pieces fit together. | | ||
| | [11. Lifecycle](./11_lifecycle.md) | Mixed: stub disposal is stable; the container and capnweb lifecycle are experimental | DO incarnations, container lifetime, capnweb session lifecycle, and hibernation. | | ||
| | [12. Worker backend](./12_worker_backend.md) | Experimental | Running the shell as just-bash inside a Dynamic Worker loaded through `env.LOADER`. | | ||
| | [13. Git interface](./13_git_interface.md) | Stable | `workspace.git` and the `git` CLI inside the shell, backed by isomorphic-git. | |
There was a problem hiding this comment.
馃攳 Git status includes experimental shell integration
The Git topic labels both workspace.git and shell git stable. Shell git runs through WorkerShellBackend, which the status table marks experimental.
Was this helpful? React with 馃憤 or 馃憥 to provide feedback.
| > [!IMPORTANT] | ||
| > Cloudflare Computer is in an early preview/experimental state and is under active, rapid development. | ||
| > Please treat any deployment as experimental and do not rely on it for production security guarantees. | ||
| > Parts of Cloudflare Computer are stable and parts are experimental. Most of it is stable. The container backends, the Worker shell backend, the `ws:container` host module, the sync between the durable object and `computerd`, `computerd` itself, and the RPC package are experimental and under active development; the [status table](../packages/computer/README.md#status) has the full list. Do not rely on the experimental components for production security guarantees. |
There was a problem hiding this comment.
馃煥 Security reports sent to public issues
When someone finds a vulnerability, the security policy directs them to open a public issue. The contribution policy requires private disclosure, so public reports can expose the flaw before remediation.
Was this helpful? React with 馃憤 or 馃憥 to provide feedback.
commit: |
LegacyContainerBackend serves containers the platform schedules from the wrangler containers block. ContainerBackend serves containers the durable object schedules itself, and is the backend new code should use, so the legacy one is now deprecated rather than listed beside it as an equal choice. LegacyContainerBackend and withLegacyWorkspaceContainer carry a @deprecated tag that names their replacements, so editors strike them through. The status table and the backend table in the package README mark the legacy backend deprecated and say what deprecated means. The multiple-backends sample and the container links point at ContainerBackend and examples/container. The entry point tables, the injected service and Worker backend documents, and the examples that still use the legacy backend say it is deprecated and name the replacement.
The security policy said parts of Cloudflare Computer are experimental but left a reader to work out which code that means. It now lists the directories and files that hold experimental code, the deprecated legacy container backend, and the directories that are not part of any published package, such as examples and test harnesses.
The notes at the top of the repository, package, and specification READMEs listed each experimental component. They now say that @cloudflare/computer is suitable for production use, that it contains work-in-progress and experimental components such as ContainerBackend that are not, and point to the package's status table, which remains the full list.
| backends: [ | ||
| new WorkerShellBackend({ id: "shell", loader: env.LOADER, /* ... */ }), | ||
| new LegacyContainerBackend({ id: "sandbox", container: () => this, /* ... */ }), | ||
| new ContainerBackend({ id: "sandbox", container: () => this, /* ... */ }), |
There was a problem hiding this comment.
馃攳 Container migration example needs full wiring
The ContainerBackend example leaves its required workspace reference inside /* ... */. Migrating from the legacy backend also needs withWorkspaceContainer and a different container configuration. Link the complete example or show that wiring here.
Was this helpful? React with 馃憤 or 馃憥 to provide feedback.
1 participant
Uh oh!
There was an error while loading. Please reload this page.