Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Bot sharing / gallery

Open
#117 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet

Research direction

Start with server/src/services/AppService.ts, server/src/api/app.ts, and middleware/resource.ts to trace app storage, owner checks, and public reads; then read ui/src/page/sample/sampleEditor.tsx and samplePage.tsx for the existing viewer and clone flow. Add tests in server/test/api.test.ts, the AppService tests, and the sample page UI tests. Done means owners can publish and unpublish bots, visitors can browse and clone published bots, and private app sources remain owner-only.

Written by the indexing model from the issue text.

Description

enhancement priority: medium

Publish a bot (read-only) for others to view and clone. Browsing real strategies is both fun and a learning tool.

Effort: M


Migrated from ENHANCEMENTS.md (§3 Competition & community).

Implementation notes

Priority: medium — Solid community-growth feature reusing an existing UI pattern, but it's opt-in/non-core-path and touches no stability-critical simulation or auth-critical paths beyond a narrow, well-precedented public-read exception.

Purpose

Lets users publish a finished bot as read-only for anyone to view and clone, growing a community gallery beyond the fixed ui/public/samples/*.js set without server code changes for every new example — the recent sample-bot viewer (commit d276549) is the exact UX precedent to generalize.

Implementation approach
  • Data model: add a public boolean default false column to the app table (server/src/services/AppService.ts, server/src/types/app.ts) — a new nullable/defaulted column is additive so it's safe under the no-migrations gap tracked in #142; add App.setPublished/isPublished mirroring setName/setSource.
  • REST: extend server/src/api/app.ts — add a toggle route (e.g. PATCH .../app/:appId/public, owner-gated like setSource) and a new open (spectator-style, like GET /api/app/:appId) listing endpoint, e.g. GET /api/apps/public, returning id/name/owner metadata only, backed by a new AppService.getPublished() query filtering public=true AND NOT deleted. Reuse the existing GET /api/app/:appId metadata route; add a source-read exception (currently requireAppOwner-gated) that permits reads when app.isPublished() is true, in middleware/resource.ts.
  • UI: reuse ui/src/page/sample/sampleEditor.tsx + samplePage.tsx pattern — either point the existing route at published apps by id (/apps/:appId viewer) or add a parallel publicAppPage.tsx; clone flow copies getSource() into a new app exactly like samplePage.tsx's clone handler, respecting MAX_APPS_PER_ARENA/MAX_APPS_PER_USER. Add a gallery list page hitting the new listing endpoint.
  • No compiler.ts bot-API surface changes; no simulation/SSE changes.
Key details to plan
  • Security: publishing exposes App.getSource() to any visitor — must NOT change requireAppOwner for write/delete/compile/reboot, only add a narrowly-scoped public-read path; keep parity with the add-by-reference model already documented in arena.ts (metadata open, source owner-gated).
  • No MCP changes required unless gallery browsing should be exposed as an MCP tool/resource (optional, out of scope for M effort).
  • Testing: extend server/test/api.test.ts for the new toggle/listing routes and the public-read exception; extend AppService tests for getPublished; UI: adapt ui/test/* sample-page-style tests (mirroring the samplePage clone-flow test) for the new public-app viewer.
  • Determinism/SSE/simulation untouched — no risk there.
  • Dependency: loosely related to #142 (DB migrations) since this is the first app-table schema change since launch; worth sequencing after or alongside it.
  • Effort/risk: matches the M label — mostly CRUD + one UI page reusing an existing pattern; main risk is scoping the source-exposure surface correctly.
Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
8m
Merged PRs (30d)
8

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LeeAdcock/robocodeJs.com

All issues in LeeAdcock/robocodeJs.com

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.