| fix(docker): move every image to bun 1.4.0 and drop the node build stages The frontend image build has been dying at `bun run build`: the Next build finishes, the output is written, and then bun 1.3.14 segfaults during process teardown, which docker reports as exit 139. Upstream already fixed it. oven-sh/bun#36866 and #37031 are a NAPI threadsafe-function use-after-free during worker teardown, both closed against oven-sh/bun#34067, which shipped in 1.4.0. There is no 1.3.15, so moving off the bug means moving to 1.4.0. Reverts the two node builder stages that were stopgaps for this, and moves the frontend runtime onto bun as well. Measured on linux/amd64 with the real Dockerfiles: 1.3.14 segfaults at 0x13CB0 every time, 1.4.0 builds clean, and the resulting image serves /api/health, server-renders, and still optimises images through sharp. Two things this drags along: - 1.4.0 writes lockfileVersion 3, so apps/web/bun.lock is regenerated and 1.3.14 can no longer read it. .bun-version, packageManager and the image tags all move together or --frozen-lockfile fails. - apps/collab keeps its node runner. @hocuspocus/server builds crossws' node adapter unconditionally and that adapter throws when it sees Bun, before the server listens. The Dockerfile now says so. Two gaps that let this ship in the first place: - apps/web/Dockerfile and apps/collab/Dockerfile had no image build in this repo. Only the root Dockerfile was covered, so the same fix had to be written twice and the broken file kept shipping. Both now build on every PR, without pushing. - Nothing checked the bun tag in a Dockerfile against .bun-version. The lockfile script now fails when they disagree. | 8 天前 |
| fix(deps): update dependency resend to v2.41.0 | 1 天前 |
| feat(scorm): support 5GB SCORM uploads (proxy timeouts + UI copy) Raising the EE SCORM package limit to 5GB requires the upload to survive long-running transfers through the frontend proxy path: - app/api/v1 proxy route: raise maxDuration 300s->3600s and the AbortController timeout 290s->3590s so multi-GB uploads on custom domains aren't cut off with a 504 mid-transfer. - docker/nginx.conf /api/v1: raise proxy_read/send_timeout 600s->3600s. - ScormActivityModal: update stale '(max 200MB)' hint to '(max 5GB)'. Body-size caps (6G) already clear 5GB, so only timeouts/copy change. | 1 个月前 |
| Merge pull request #1062 from learnhouse/feat/h5p-sizing-and-optional-due-dates Add H5P size modes and optional assignment due dates | 1 天前 |
| fix(docker): move every image to bun 1.4.0 and drop the node build stages The frontend image build has been dying at `bun run build`: the Next build finishes, the output is written, and then bun 1.3.14 segfaults during process teardown, which docker reports as exit 139. Upstream already fixed it. oven-sh/bun#36866 and #37031 are a NAPI threadsafe-function use-after-free during worker teardown, both closed against oven-sh/bun#34067, which shipped in 1.4.0. There is no 1.3.15, so moving off the bug means moving to 1.4.0. Reverts the two node builder stages that were stopgaps for this, and moves the frontend runtime onto bun as well. Measured on linux/amd64 with the real Dockerfiles: 1.3.14 segfaults at 0x13CB0 every time, 1.4.0 builds clean, and the resulting image serves /api/health, server-renders, and still optimises images through sharp. Two things this drags along: - 1.4.0 writes lockfileVersion 3, so apps/web/bun.lock is regenerated and 1.3.14 can no longer read it. .bun-version, packageManager and the image tags all move together or --frozen-lockfile fails. - apps/collab keeps its node runner. @hocuspocus/server builds crossws' node adapter unconditionally and that adapter throws when it sees Bun, before the server listens. The Dockerfile now says so. Two gaps that let this ship in the first place: - apps/web/Dockerfile and apps/collab/Dockerfile had no image build in this repo. Only the root Dockerfile was covered, so the same fix had to be written twice and the broken file kept shipping. Both now build on every PR, without pushing. - Nothing checked the bun tag in a Dockerfile against .bun-version. The lockfile script now fails when they disagree. | 8 天前 |
| fix(docker): move every image to bun 1.4.0 and drop the node build stages The frontend image build has been dying at `bun run build`: the Next build finishes, the output is written, and then bun 1.3.14 segfaults during process teardown, which docker reports as exit 139. Upstream already fixed it. oven-sh/bun#36866 and #37031 are a NAPI threadsafe-function use-after-free during worker teardown, both closed against oven-sh/bun#34067, which shipped in 1.4.0. There is no 1.3.15, so moving off the bug means moving to 1.4.0. Reverts the two node builder stages that were stopgaps for this, and moves the frontend runtime onto bun as well. Measured on linux/amd64 with the real Dockerfiles: 1.3.14 segfaults at 0x13CB0 every time, 1.4.0 builds clean, and the resulting image serves /api/health, server-renders, and still optimises images through sharp. Two things this drags along: - 1.4.0 writes lockfileVersion 3, so apps/web/bun.lock is regenerated and 1.3.14 can no longer read it. .bun-version, packageManager and the image tags all move together or --frozen-lockfile fails. - apps/collab keeps its node runner. @hocuspocus/server builds crossws' node adapter unconditionally and that adapter throws when it sees Bun, before the server listens. The Dockerfile now says so. Two gaps that let this ship in the first place: - apps/web/Dockerfile and apps/collab/Dockerfile had no image build in this repo. Only the root Dockerfile was covered, so the same fix had to be written twice and the broken file kept shipping. Both now build on every PR, without pushing. - Nothing checked the bun tag in a Dockerfile against .bun-version. The lockfile script now fails when they disagree. | 8 天前 |
| chore: add .dockerignore file and update Dockerfile for improved build process and environment management for self hosting | 1 年前 |
| feat: add the demo entry points, routes and tests /demo/status and /demo/enter, and the surfaces that use them: an entry card on onboarding and the org picker, a DEMO badge so a shared sandbox is never mistaken for one of your own organizations, and a banner that says what the demo is and counts down to the next reset. The banner is fixed to the top of the dash column rather than sitting in flow — several dash pages are h-screen with their own inner scrolling, so a strip in flow made the column taller than the viewport, and the bottom edge is where the save bars and the mobile menu live. Copy goes through i18n like the rest of the app, and robots.txt asks the API whether an org is the demo before allowing it to be indexed. Tests cover the bundle, the sync, the exclusions, teardown and the routes. Several assert the negative case too, because a guard that is never exercised is a guard that quietly stops working: entering the demo must not consume a free-org slot, and the members filter must not touch a real organization. The 403 assertions are pinned to the guard's own message — RBAC answers 403 here as well, and one of these tests was passing for that reason rather than the intended one. Two unrelated test fixes, both the same shape: an opt-in live suite that failed instead of skipping on a developer machine. The Ollama tests checked that the port answered but not that the model was pulled, and the superadmin token tests imported the Enterprise package without forcing the deployment mode that makes those code paths reachable. DEMO_STACK.md documents running it locally; the scripts generate their own secrets rather than carrying any. | 16 天前 |
| ci: make bun.lock the only web lockfile and verify lockfiles in CI Every Renovate PR broke the same way: the Docker build and next-lint failed on `bun install --frozen-lockfile` with "lockfile had changes, but lockfile is frozen", api-tests failed on `uv sync`, and someone regenerated the lockfile by hand. apps/web carried two lockfiles. bun.lock is what the Dockerfiles and every CI install read; pnpm-lock.yaml existed only so the dependency scanner could resolve the transitive tree. Renovate picks one package manager per directory, picked pnpm, and left bun.lock alone. Before pnpm-lock.yaml was added Renovate updated bun.lock and none of this happened. So pnpm-lock.yaml is deleted, along with the duplicated `pnpm.overrides` block that had already drifted from `overrides` (missing lodash, lodash-es — enough for pnpm to reject its own lockfile with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH). apps/web declares `packageManager: bun@1.3.14`, matching .bun-version, so npm, pnpm and yarn refuse to run there and cannot recreate a second lockfile. The dependency scan now resolves apps/web from bun.lock or from package.json. That leaves the other source of drift: a version bump edited by hand touches pyproject.toml or package.json and no lockfile at all — which is how the 1.3.4 bump landed. scripts/lockfiles.sh regenerates or verifies all of them (bun.lock in apps/web, apps/collab, apps/cli, apps/e2e, docs, plus apps/api/uv.lock) with the same commands CI and Docker run. The Lockfiles workflow runs it on every PR that touches a manifest and on dev, and on dependency-bot branches it commits the regenerated files back rather than only failing. Setting LOCKFILE_SYNC_TOKEN makes that commit re-trigger the other checks. renovate.json changes for two upgrades that can only ever be red: - workos declares a floor on cryptography and both are pinned exactly, so splitting them across PRs leaves neither resolvable. Grouped. - typescript is capped below 7; @typescript-eslint 8.66 still crashes on the native compiler with "Cannot read properties of undefined (reading 'Cjs')", which fails next-lint with ESLint exit 2. apps/api/bun.lock is deleted too — there is no package.json next to it. | 21 天前 |
| feat: add the demo entry points, routes and tests /demo/status and /demo/enter, and the surfaces that use them: an entry card on onboarding and the org picker, a DEMO badge so a shared sandbox is never mistaken for one of your own organizations, and a banner that says what the demo is and counts down to the next reset. The banner is fixed to the top of the dash column rather than sitting in flow — several dash pages are h-screen with their own inner scrolling, so a strip in flow made the column taller than the viewport, and the bottom edge is where the save bars and the mobile menu live. Copy goes through i18n like the rest of the app, and robots.txt asks the API whether an org is the demo before allowing it to be indexed. Tests cover the bundle, the sync, the exclusions, teardown and the routes. Several assert the negative case too, because a guard that is never exercised is a guard that quietly stops working: entering the demo must not consume a free-org slot, and the members filter must not touch a real organization. The 403 assertions are pinned to the guard's own message — RBAC answers 403 here as well, and one of these tests was passing for that reason rather than the intended one. Two unrelated test fixes, both the same shape: an opt-in live suite that failed instead of skipping on a developer machine. The Ollama tests checked that the port answered but not that the model was pulled, and the superadmin token tests imported the Enterprise package without forcing the deployment mode that makes those code paths reachable. DEMO_STACK.md documents running it locally; the scripts generate their own secrets rather than carrying any. | 16 天前 |
| fix(docker): move every image to bun 1.4.0 and drop the node build stages The frontend image build has been dying at `bun run build`: the Next build finishes, the output is written, and then bun 1.3.14 segfaults during process teardown, which docker reports as exit 139. Upstream already fixed it. oven-sh/bun#36866 and #37031 are a NAPI threadsafe-function use-after-free during worker teardown, both closed against oven-sh/bun#34067, which shipped in 1.4.0. There is no 1.3.15, so moving off the bug means moving to 1.4.0. Reverts the two node builder stages that were stopgaps for this, and moves the frontend runtime onto bun as well. Measured on linux/amd64 with the real Dockerfiles: 1.3.14 segfaults at 0x13CB0 every time, 1.4.0 builds clean, and the resulting image serves /api/health, server-renders, and still optimises images through sharp. Two things this drags along: - 1.4.0 writes lockfileVersion 3, so apps/web/bun.lock is regenerated and 1.3.14 can no longer read it. .bun-version, packageManager and the image tags all move together or --frozen-lockfile fails. - apps/collab keeps its node runner. @hocuspocus/server builds crossws' node adapter unconditionally and that adapter throws when it sees Bun, before the server listens. The Dockerfile now says so. Two gaps that let this ship in the first place: - apps/web/Dockerfile and apps/collab/Dockerfile had no image build in this repo. Only the root Dockerfile was covered, so the same fix had to be written twice and the broken file kept shipping. Both now build on every PR, without pushing. - Nothing checked the bun tag in a Dockerfile against .bun-version. The lockfile script now fails when they disagree. | 8 天前 |
| Initial commit | 4 年前 |
| tests: enhance test coverage with new import/export and organization CRUD tests | 4 个月前 |
| fix: internal and security issues | 4 个月前 |
| fix(web): pair the KaTeX stylesheet with the renderer rehype-katex and react-katex both resolve katex ^0.16, but apps/web carried a direct katex ^0.18. KaTeX 0.18 renamed the layout classes (.base -> .katex-base, .strut, .sizing), so the stylesheet we import had no rules for the markup the two libraries actually produce: superscripts rendered full size and fractions lost their alignment. Editor math blocks were already affected; the copilot inherits it. Cap the range at the 0.16 line and tell Renovate why, so the next major bump does not silently break it again. | 5 天前 |
