Establish consumer/distribution test strategy

Open
  • Is something wrong?
#1,135 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
express, react, typescript, vite
Domain
backend, build-system, frontend, testing

Research direction

Start with the package and generator entry points that produce the SDK/React/store/generator npm tarballs, then inspect the proposed code/apps/reference-frontend and code/apps/reference-backend shapes. Run the consumer flow against npm pack tarballs in Chromium, including rectangle, a second node type, undo/redo, reconnect, and concurrent collaboration cases. Done means the reference apps work as real consumers without changing existing templates, with Firefox nightly coverage added.

Written by the indexing model from the issue text.

Description

enhancement

Summary

Add a testing layer that validates Weave.js as consumers actually experience it: packed npm tarballs, generator output, and real browser-to-browser WebSocket collaboration. Two new minimal, non-published reference apps (code/apps/reference-frontend  Vite+React, code/apps/reference-backend Express+WS) exercise a rectangle + a second node type + undo/redo plugin + collaboration (including a concurrent-edit convergence case), tested against  npm pack  tarballs of the SDK/React/store/generator packages — Chromium on PRs, +Firefox nightly. Existing generator templates stay untouched; the canonical Vite+React/Express+WS shape is added as a new, additional generator option.

Basic example

Two clients open reference-frontend, connected via reference-backend. Client A creates a rectangle and updates it; Client B renders the same state and reconnects to see current state. Packages are installed via  npm pack  tarballs (not workspace links) to catch broken exports/types/peer-deps as a real npm consumer would hit them.

Motivation

Current tests prove package internals, not that published artifacts install and work for real consumers. This can let broken exports, omitted files, peer-dependency issues, generator/starter drift, or collaboration regressions reach a release. This adds an explicit, additive (nothing removed/replaced) validation layer for that gap, without duplicating existing unit-test coverage. Out of scope: performance/load testing and live Azure Web PubSub e2e (kept mock/contract-tested only).

Dominant language
TypeScript
Stars
276
Forks
26
Avg merge
1d 10h
Merged PRs (30d)
47

Getting set up

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 InditexTech/weavejs

All issues in InditexTech/weavejs

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.