2026-09-16 19:24:59 +02:00
|
|
|
{
|
|
|
|
|
"version": "2.0.0",
|
|
|
|
|
"tasks": [
|
|
|
|
|
{
|
|
|
|
|
"label": "serverpod_start",
|
|
|
|
|
"type": "shell",
|
|
|
|
|
"command": "serverpod",
|
2026-09-30 11:06:50 +02:00
|
|
|
"args": ["--no-analytics", "start"],
|
2026-09-16 19:24:59 +02:00
|
|
|
"options": {
|
build: Melos, a Dart check and every path for the single repository
- Melos 8.9 as the root's dev dependency, with scripts across the
workspace (analyze, test:dart, test:flutter, generate, check) and its
filters (--diff, --include-dependents); cli_util overridden to 0.5.2
for it, since Learn's flutter_launcher_icons asks for 0.4 and uses only
its logger, unchanged in 0.5.
- tool/check.dart in place of tool/check.sh: packages, formatting of our
own files, analysis, the tools' tests, then every package's tests
through Melos (--changed-since=<commit> for only what changed and what
depends on it). tool/pre-push is the hook: the signature check, then
the checks. CI generates every server's code and runs the same check.
- The images build from the root with a workspace narrowed to what they
need (tool/workspace_only.sh); compose, the deploy's migration test,
the snap, the release script, the editor's launch files and Learn's
asset tools (run from apps/learn) follow the new layout.
- The project's source is named as project-halkyon/halkyon (source link,
snap, F-Droid listing, release uploads); the AGPL packages carry the
licence's own text.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>
2026-10-19 20:39:09 +02:00
|
|
|
"cwd": "${workspaceFolder}/apps/learn/halkyon_learn_server",
|
2026-09-16 19:24:59 +02:00
|
|
|
"env": {
|
|
|
|
|
// Marks a `serverpod start` launched from the IDE, which is the
|
|
|
|
|
// only kind that honors the Flutter device picked in VS Code. A run
|
|
|
|
|
// started from a plain terminal carries no marker, so a device file
|
|
|
|
|
// left behind by a session that was killed cannot retarget it.
|
|
|
|
|
"SERVERPOD_LAUNCHED_FROM_IDE": "true"
|
|
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
"isBackground": true,
|
|
|
|
|
"presentation": {
|
|
|
|
|
"reveal": "always",
|
|
|
|
|
"panel": "dedicated"
|
|
|
|
|
},
|
|
|
|
|
// The TUI captures stdout, so we can't string-match for "ready". The
|
|
|
|
|
// attach config polls vm-service-info.json for the actual readiness
|
|
|
|
|
// signal; this matcher exists only to satisfy VS Code's requirement
|
|
|
|
|
// that background tasks declare one. The pattern intentionally never
|
|
|
|
|
// matches; begin/end patterns mark the task active+ready immediately.
|
|
|
|
|
"problemMatcher": {
|
|
|
|
|
"owner": "serverpod",
|
|
|
|
|
"pattern": [
|
|
|
|
|
{
|
|
|
|
|
"regexp": "^(SERVERPOD_NEVER_MATCH):(\\d+):(.+)$",
|
|
|
|
|
"file": 1,
|
|
|
|
|
"line": 2,
|
|
|
|
|
"message": 3
|
|
|
|
|
}
|
|
|
|
|
],
|
|
|
|
|
"background": {
|
|
|
|
|
"activeOnStart": true,
|
|
|
|
|
"beginsPattern": ".",
|
|
|
|
|
"endsPattern": "."
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
]
|
|
|
|
|
}
|