[renovate]

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
@tailor-platform/sdk (source)	2.22.0 → 2.28.0

---

Release Notes

tailor-platform/sdk (@​tailor-platform/sdk)

v2.28.0

Compare Source

Minor Changes

• #​2589 4bf9fd5 Thanks @​dqn! - Default to JSON output when an AI coding agent such as Claude Code, Codex, Cursor, or Gemini CLI runs tailor, so the agent reads parseable output even without the bundled agent skill, and start --help with guidance for the agent. Pass --json=false or set TAILOR_JSON_OUTPUT=false to keep table output under an agent, or set POLITTY_NO_AGENT=1 to turn agent detection off. CLI plugins keep their current output.

• #​2595 928a0cf Thanks @​toiroakr! - Add tailor data clone to copy the data of an application from one workspace to another, and tailor data operation get to check on a started clone or wait for it with --wait. It copies the TailorDB namespaces registered in the application's subgraph; --copy-files and --copy-idp-users also copy TailorDB file content and IdP users. --name defaults to the application name in the config file. data clone waits for the clone to finish; pass --no-wait to start it and exit.

• #​2595 a99be0b Thanks @​toiroakr! - Add --clone-timeout to tailor tailordb migration test to set how long --data clone waits for the data clone to finish, for example 30s or 10m. The default is now 30 minutes, up from 5, and the option is rejected with --data seed. If your CI job time limit is shorter than 30 minutes, pass a shorter --clone-timeout so the command can time out and delete its temporary workspace before the job is stopped.

• #​2595 a99be0b Thanks @​toiroakr! - Add --keep-ttl to tailor tailordb migration test to record an expiry, for example 24h or 7d, on the temporary workspace that --keep retains, so tailor workspace prune --expired can delete it later. It requires --keep.

• #​2586 65b793b Thanks @​dqn! - Keep scenario and per-environment seed data side by side as datasets: directories under <distPath>/data/ holding JSONL rows for some of the tables. tailor seed apply, validate, and fill take --dataset <name> (repeatable) to use datasets on top of the base seed data, and tailor seed dump --dataset <name> writes into one. --all-datasets selects every dataset directory in name order for apply, validate, and fill, including gitignored local datasets and directories added later; it cannot be combined with --dataset, and fails if no dataset directories exist. apply --truncate --all-datasets keeps the existing truncate scope and confirmation. validate checks foreign keys across the base data and the selected datasets and reports an id defined in more than one of them at its own file and line; apply rejects such an id before it changes anything. --no-base applies or validates the selected datasets alone, so a dump written with --dataset restores on its own. Name the combinations you use in the new datasets option of seedPlugin (for example datasets: { preview: ["cogs", "shipments"] }) to select them with one --dataset. Projects without datasets work as before, except that tailor seed apply now reads all seed rows before truncating or seeding anything, so a malformed file stops the run with the workspace untouched. Naming a dataset directory, or a file in one, as the path of tailor seed validate or fill points you at --dataset.

• #​2600 ea634ba Thanks @​ikawaha! - Add the gapless option to .serial() (preview), which numbers records without gaps: a number is used only by a create that commits.

• #​2583 23b3b36 Thanks @​dqn! - Add maintenanceMode to defineConfig() to choose whether tailor deploy restricts the TailorDB namespaces it migrates while pending migrations run. "migration" restricts them (no generated GraphQL create, update, delete, or bulk upsert, and no record events) until the migrations complete, as every deploy did before; "deploy" keeps them restricted until the deploy has also applied resolvers, executors, and workflows, so executors from the previous deploy do not receive events from the migrated tables while the deploy replaces them; false does not restrict them.

  Tables that a deploy left restricted after its migrations completed, for example because the deploy was interrupted, no longer make the next deploy stop with remote schema drift; that deploy releases them when it applies its TailorDB changes.

  Restoring table settings after a failed migration no longer fails for a table whose checkpoint sets publishEvents: false while an executor in the same deploy subscribes to it, which left that table restricted.

• #​2577 eab2d88 Thanks @​dqn! - Show how long tailor deploy keeps tables in maintenance mode while it applies TailorDB migrations. Deploy now tells waiting for a migration job to start apart from the script running: it reports when the script starts running, how long it waited and ran, and a summary of the whole maintenance window by phase. tailor deploy --json returns the same breakdown under tailordbMaintenance. Each migration job now logs [tailor-sdk] migration script started before the script runs.

• #​2579 a139e89 Thanks @​dqn! - Add tailor user update --default-organization-id <id> [--default-folder-id <id>] to store where tailor workspace create, workspace creation during deploy, and the programmatic createWorkspace() put new workspaces when neither organization nor folder is given. The defaults are kept per user and platform, and any explicit organization or folder, including through TAILOR_PLATFORM_ORGANIZATION_ID / TAILOR_PLATFORM_FOLDER_ID for CLI commands, replaces both. deploy --create-workspace also uses the resolved default location when checking whether an existing workspace matches. workspace create, deploy --create-workspace, and the programmatic createWorkspace() now reject a folder ID without an organization ID with a clear error instead of failing with an internal error.

  workspace create and deploy now use organization and folder IDs from --env-file, even when no user defaults are stored. Previously these values were ignored; a folder-only env file now fails unless an organization is also given. Command-line options take precedence, and empty env-file values are treated as not given.

Patch Changes

• #​2609 1c36c61 Thanks @​toiroakr! - tailor deploy now warns when an IdP permission rule allows every authenticated user (a condition on _loggedIn, such as [{ user: "_loggedIn" }, "=", true], as its only condition). Such a rule lets any signed-in user run that operation against any IdP user, for example reading and changing login information such as email addresses or sending password reset emails to anyone. The deploy still succeeds; restrict the rule to an administrator role unless every user who can sign in is trusted.

• #​2588 3de270f Thanks @​dqn! - Update @politty/zod to 0.4.3. A positional argument is no longer accepted under its own name as an option, so pass the value positionally: tailor profile create dev, not tailor profile create --name dev. Most commands report such an option as unknown; a few, such as tailor completion and npm create @tailor-platform/sdk, only warn and ignore it. tailor secret vault create --name, tailor secret vault delete --name, and tailor tailordb truncate --tables, which the documentation and earlier release notes use, still accept both forms. Mixing the two forms, as in tailor tailordb truncate --tables User Order, is rejected; repeat the option for each table, as in --tables User --tables Order.

• #​2578 b57a21f Thanks @​dqn! - Keep settings that a newer SDK version wrote to the CLI config file (~/.config/tailor-platform/config.yaml) when this version rewrites the file, for example after logging in or refreshing a token, instead of silently dropping them.

• #​2580 9c54e51 Thanks @​dqn! - Clarify in tailor workspace prune --help and error suggestions that location options must be given on the command line and that the defaults from tailor user update are not used. Warn before an unscoped sweep that every visible workspace is a candidate for the name and age filters, including with --yes or --dry-run.

• #​2612 34a67e3 Thanks @​toiroakr! - Reject .serial() on fields inside db.object(). TailorDB cannot number a serial field nested in an object, so a create that omitted the value failed with an internal error. It is now a type error, and a build that still defines one fails; remove .serial() from the nested field (or move the field out of the object) to upgrade.

• #​2556 56abcc9 Thanks @​renovate! - fix(deps): update @​​inquirer

• #​2604 4dde6ea Thanks @​renovate! - chore(deps): update dependency @​​types/node to v24.19.2

• #​2607 b517e0a Thanks @​renovate! - fix(deps): update dependency @​​napi-rs/keyring to v2.1.1

• #​2611 938f418 Thanks @​renovate! - fix(deps): update rolldown

v2.27.0

Compare Source

Minor Changes

• #​2570 80624d1 Thanks @​dqn! - @tailor-platform/sdk/cli now exports WORKSPACE_NAME_MAX_LENGTH, the maximum number of characters in a workspace name, so plugins can size names derived from a workspace name without hardcoding the limit.

• #​2526 95952c9 Thanks @​toiroakr! - Add defaultDateRepresentation to defineConfig(). Setting it to "temporal" gives t.date(), t.datetime(), and t.time() fields that omit as Temporal values (Temporal.PlainDate, Temporal.Instant, Temporal.PlainTime) instead of strings, so a project can use Temporal everywhere without repeating as: "temporal"; "date" gives them Date values the same way. A field's own as, including as: "string", still takes precedence; db.* fields are unaffected. Run tailor generate after changing the setting so tailor.d.ts updates the field types.

  The default is applied in every bundled function (resolvers, executors, workflow jobs, auth hooks, TailorDB hooks and validators, migration scripts), in tailor function run, and in the tailor-runtime Vitest environment when tailorRuntime({ config }) points at the config (the config is read once when Vitest starts; a missing or unparsable config, or a value other than "temporal" or "date", fails the run, while a config that throws while loading prints a warning and keeps string values, as it already does for secrets). Under "temporal", every resolver bundle keeps the Temporal conversion, so .parse() on a field declared inside body works too. Each migration records the representation in effect when its script was generated and keeps running with it; a migration generated under "temporal" or "date" is written as format version 8, which older SDK versions refuse to read, and every generated migrate.test.ts scaffold calls the new applyDateRepresentation helper from @tailor-platform/sdk/vitest with the recorded value ("string" when none is recorded) before importing the script, so the test runs it with the same values (tests of "temporal" migrations run in the tailor-runtime Vitest environment, which provides Temporal). tailor.d.ts now declares the setting per application, keyed by the application name; when several applications' tailor.d.ts files are included in one TypeScript program and disagree, calling a date builder without as is a type error until they are aligned.

  For projects that never set the option: t.date()/t.datetime()/t.time() now record as: "default" (and an explicit as: "string") in their metadata, tailor.d.ts gains a DateRepresentationRegistry entry ("<app>": "unset"), and the resolver, executor, workflow job, and auth hook bundle caches are rebuilt once on the next deploy.

• #​2573 66a8d86 Thanks @​dqn! - Show why each function execution failed in tailor function logs. Every execution now includes errorKind (USER_RUNTIME, USER_NON_RUNTIME, PLATFORM, NONE, or UNSPECIFIED), errorName, and errorMessage, so the list tells you whether a failure came from your code or the Platform without opening each execution. The list table shows errorKind and errorName; --json and the execution details also include errorMessage.

• #​2551 5c17144 Thanks @​k1LoW! - Expose when a Built-in IdP user's password was last set. The runtime idp.Client User records now include passwordUpdatedAt (an ISO 8601 string, or null for users without a password), and the Auth beforeLogin hook claims are typed with password_updated_at (seconds since the Unix epoch), so applications can enforce their own password expiration.

• #​2566 0a7a369 Thanks @​toiroakr! - Add tailor deploy --migration-skip-steps <namespace>/<step>,... to skip the steps of a multi-step TailorDB migration that already succeeded when a changed step list makes the migration run every step again, and make the warning shown in that case list the steps that already succeeded and say how to skip them

• #​2546 613d6a4 Thanks @​toiroakr! - tailor tailordb migration generate and tailor tailordb migration script now scaffold migrate.ts as a multi-step script that exports steps. It has one step for each schema change that needs a data migration, and steps that touch the same field are ordered with dependsOn. migration script --with-test writes the test scaffolds against steps when migrate.ts exports it.

  Where a generated migrate.ts leaves a value or logic for you to decide, such as what an added required field holds in existing records, it now calls TODO(message) from ./db instead of writing null next to a // TODO: comment or a never annotation. The migration fails at that call, and tailor tailordb migration validate and tailor deploy reject a migrate.ts that still calls it before anything is changed. tailor deploy also rejects a migrate.ts that still carries the TODO(tailor-migration-review) marker earlier versions generated, which only migration validate checked before.

• #​2504 b7cbbb4 Thanks @​dqn! - A TailorDB migration script can now export steps instead of main to split its data migration into steps. Each step runs as its own job in its own transaction, so a long migration is no longer bound by a single job's execution-time limit, and dependsOn declares which steps must complete before another starts.

  import type { MigrationSteps } from "./db";
  
  export const steps = {
    backfillInvoice: {
      run: async (trx) => {
        /* ... */
      },
    },
    recomputeTotals: {
      dependsOn: ["backfillInvoice"],
      run: async (trx, { env }) => {
        /* ... */
      },
    },
  } satisfies MigrationSteps;

  When a step fails after other steps completed, tailor deploy keeps the migration in progress instead of rolling it back: the next deploy resumes it from the steps that have not completed, and tailordb migration status reports it. A script with a single step runs like a main script, in one transaction: a failure inside it rolls its data changes back, and a failure in the post-migration schema changes restores the schema while the next deploy runs the step again. Steps must be safe to run again. runMigrationSteps in @tailor-platform/sdk/vitest runs steps in tests the same way. Scripts that export main behave as before; a script that exports both runs main and warns that steps is ignored.

Patch Changes

• #​2549 736faf2 Thanks @​toiroakr! - Document that tailor deploy --json writes exactly one JSON object to stdout and sends progress and diagnostics to stderr, and that deploy plugins report through ctx.logger and ctx.exec to keep that output parseable.

• #​2582 169a486 Thanks @​dqn! - tailor function logs <execution-id> no longer shows a stray : in the error when its name or message is empty. An execution the Platform aborted because of its own deadline or cancellation, which has no error name, now shows just its message.

• #​2550 18e4dfb Thanks @​toiroakr! - Restrict the defineIdp permission examples in the docs, the IdPPermission JSDoc, the example project and the static-web-site template to an administrator role, and warn in the IdP docs that a _loggedIn policy lets every authenticated user read and change other users' login information and send password reset emails

• #​2531 fb86a11 Thanks @​haru0017! - Correct the job function timeout in the Executor service docs to 5 minutes.

• #​2569 80cbc74 Thanks @​toiroakr! - Stop disabling the GraphQL read operation of a table while tailor deploy applies a TailorDB migration. Create, update, delete, and bulk upsert are still disabled and record events are still not published. read keeps the table's live setting when the restrictions begin, and a table that a migration touches then follows that migration's schema, so a migration that changes read changes it before its script runs

• #​2562 892a813 Thanks @​dqn! - When tailor deploy cannot confirm whether a TailorDB migration that runs in one transaction (a script that exports main, or steps with a single step) started or finished, it no longer removes the run and rolls back the migration's schema changes while the script may still be running. It reports the outcome as unconfirmed, keeps the namespace in maintenance mode, and explains how to check the run and settle the migration. A later deploy refuses to run the migration again while that run is still executing. While the script runs, the deploy now keeps waiting while the platform is temporarily unavailable instead of giving up.

• #​2566 8405305 Thanks @​toiroakr! - Make tailor deploy report which TailorDB tables stay restricted when a failed migration cannot be fully restored or rolled back, and give recovery steps and --json error context for a skipped restoration after a checkpoint conflict or an unverifiable checkpoint

• #​2559 cf8da6b Thanks @​toiroakr! - tailor tailordb migration test no longer fails when the source namespace was deployed without a migration label (for example, before it adopted SDK migrations). Like tailor deploy, it treats the namespace as being at migration 0 and tests 0001 onward, provided the namespace's schema matches the 0000 snapshot; otherwise it fails and shows the differences.

• #​2539 228487c Thanks @​toiroakr! - List the workspace regions in tailor workspace create --help in the order the Platform returns them (asia-northeast, us-west)

• #​2509 54f95b9 Thanks @​renovate! - chore(deps): update dependency @​​types/node to v24.19.1

• #​2521 1910e15 Thanks @​renovate! - fix(deps): update dependency @​​bufbuild/protobuf to v2.16.0

• #​2524 9210a2d Thanks @​renovate! - fix(deps): update dependency @​​toiroakr/lines-db to v0.14.0

• #​2528 d8c2825 Thanks @​renovate! - fix(deps): update secretlint monorepo to v13.0.7

• #​2535 75b61a0 Thanks @​renovate! - fix(deps): update dependency globals to v17.13.0

• #​2536 248ea98 Thanks @​renovate! - fix(deps): update dependency oxc-parser to v0.152.0

• #​2537 a99da7d Thanks @​renovate! - fix(deps): update dependency std-env to v4.3.0

• #​2540 0d8bc9c Thanks @​renovate! - fix(deps): update dependency @​​toiroakr/lines-db to v0.15.0

• #​2543 2547d99 Thanks @​toiroakr! - fillSeedData (tailor seed fill) now refuses to write any file when a seed JSONL file was changed by another tool after the fill read it, instead of overwriting that change, and fills the first row of a file that starts with a byte order mark instead of skipping it

• #​2538 7485f14 Thanks @​toiroakr! - tailor setup ci env and the GitHub Actions guide now tell an organization or folder admin to create the platform machine user in the Tailor Console and grant it a role, and say that without the required permission you cannot view or create machine users, instead of telling you to contact Tailor support

• #​2570 88e17e9 Thanks @​dqn! - tailor setup ci preview now rejects a name longer than 50 characters. Each pull request's preview workspace is named <name>-pr-<number>, which must fit in 63 characters, so a longer name made preview deploys fail once pull request numbers grew (from the first pull request for names of 59 characters or more). A preview workflow already recorded in .github/tailor.lock under a longer name still regenerates, for example with tailor setup update, with a warning naming the first pull request number whose preview deploy fails.

• #​2571 d6527ca Thanks @​dqn! - tailor setup ci preview now cancels the whole superseded preview run, including the jobs you added with needs: tailor-preview-deploy, so they no longer keep running against a preview workspace that a newer run is redeploying or that closing the pull request deletes. Run tailor setup update to regenerate existing preview workflows; a top-level concurrency: you already set in one is kept in place of the new default.

• #​2574 e2619b3 Thanks @​dqn! - tailor setup ci branch and tailor setup ci preview now generate a final job, tailor-result and tailor-preview-result, whose check (such as tailor-result (my-app)) reports whether the whole workflow passed, so branch protection needs only that one check instead of every job. It fails when a job it needs failed or was cancelled and passes when they succeeded or were skipped. Add your own jobs, such as end-to-end tests or a matrix job, to its needs to make them count; regenerating the workflow keeps them, and tailor setup check does not report them as hand edits.

  Run tailor setup update to add the job to existing workflows with the flags they were generated with; tailor setup check reports them as outdated until then. If every managed job uses the same runs-on you set, for example self-hosted runners, the new job uses it too; otherwise, set it on the new job yourself.

• #​2546 649ca55 Thanks @​toiroakr! - When tailor deploy loses the response to starting a TailorDB migration that runs in one transaction (a script that exports main, or steps with a single step), it now waits for the migration that the platform started instead of removing it and rolling the schema back while it runs.

• #​2504 13143fd Thanks @​dqn! - Starting a workflow, from tailor workflow start or for a TailorDB migration during tailor deploy, is no longer retried after a transient platform error, because the retry could start a second execution.

v2.26.0

Compare Source

Minor Changes

• #​2525 d21806e Thanks @​dqn! - These state-changing commands now print a JSON result on stdout under --json instead of leaving it empty: authconnection delete, authconnection revoke, organization folder delete, secret create, secret update, secret delete, secret vault delete, workspace delete, workspace restore, workspace user remove, tailordb truncate, tailordb migration set, tailordb migration rebaseline, tailordb migration sync, and tailordb migration generate. Each result carries the same changed boolean as the other commands: for example, tailordb migration set to the checkpoint and migration history ID already in place, and tailordb migration generate with no migration to write, report false. Under --json, tailordb migration generate and tailordb migration script no longer open the file they create in the editor set by VISUAL or EDITOR, which would otherwise write to the same stdout. Output without --json is unchanged.

• #​2470 090297d Thanks @​toiroakr! - Add a temporal option to kyselyTypePlugin. When enabled, date/datetime fields and top-level time fields resolve to Temporal.PlainDate/Temporal.Instant/Temporal.PlainTime (instead of Date/string) in generated Kysely types, migration db.ts files, and tailor function script types, and the generated getDB() reads them back as those values. Nested time fields remain strings. The mode is fixed by the plugin setting; getDB() takes no temporal option.

  Each migration records whether its db.ts was generated with Temporal types, and deploy runs that migration's script in the same mode, so migrations generated before temporal was enabled keep receiving Date values. Migration files are now written as format version 7, which older SDK versions refuse to read. mockTailordbWithPGlite and createKyselyPGlite (with { temporal: true }) return Temporal values from PGlite to match, and accept Temporal values as query parameters.

v2.25.0

Compare Source

Minor Changes

• #​2449 e4a0301 Thanks @​toiroakr! - tailor open and tailor auth-connection open now always open the new Tailor Platform Console UI, which has replaced the previous UI at console.tailor.tech. tailor open opens /workspaces/{workspaceId}/services/applications/{applicationName} (previously /workspaces/{workspaceId}/applications/{applicationName}/overview), and tailor auth-connection open opens /workspaces/{workspaceId}/services/auth-connections (previously /workspaces/{workspaceId}/settings/connections). The TAILOR_CONSOLE_NEXT environment variable is no longer read: a leftover TAILOR_CONSOLE_NEXT=1 no longer redirects the console host to console-next., so it can be removed.

• #​2468 3c87be0 Thanks @​toiroakr! - Add an onDeployed plugin hook with deployed application IDs and URLs, public OAuth client IDs, and publishing to static websites. Hooks run after successful deploys, including deploys without resource changes, and can return structured JSON outputs.

• #​2468 7451944 Thanks @​toiroakr! - Add frontendPlugin from @tailor-platform/sdk-plugin-frontend to build and upload frontend assets during tailor deploy. Frontend builds can use deployed URLs and public OAuth client IDs as environment variables, and deployment results include uploaded frontend details in outputs.frontends.

  Add deployment hooks and shared context types to @tailor-platform/sdk. Successful tailor deploy --json results now include workspaceId and applications with deployed application, Static Website, and AI Gateway URLs, plus public OAuth client IDs, even when no deploy plugins are configured.

• #​2505 3296f08 Thanks @​dqn! - More state-changing commands now print a JSON result on stdout under --json, so scripts can confirm what changed without parsing stderr: login, logout, remove, profile delete, user switch, user pat delete, secret vault create, authconnection authorize, workspace user invite, workspace user update, workspace ttl set, workspace ttl clear, crashreport send, and tailordb migration script. Each result carries a changed boolean: true when the command did work, false when it did nothing, such as logout when nobody is logged in, user switch to the current user, or workspace ttl clear on a workspace with no TTL. Output without --json is unchanged.

• #​2497 efcca78 Thanks @​tailor-bobbin! - Include the machine user id in tailor machineuser list output so machine users can be matched against the invoker id available in resolvers and executors.

• #​2486 caa34b4 Thanks @​dqn! - tailor secret create and tailor secret update now read the secret value from standard input when --value is omitted, keeping it out of shell history and process listings: printf '%s' "$VALUE" | tailor secret create --vault-name <vault> --name <name>. The piped value can be up to 128 KiB, and one trailing newline is removed from it. Without --value, a terminal or empty standard input fails with SECRET_VALUE_REQUIRED.

• #​2485 d06f314 Thanks @​dqn! - tailor show (and the programmatic show()) now also lists each deployed static website defined in staticWebsites with its URL and description, and each deployed OAuth2 client defined in auth's oauth2Clients with its client ID, so a CI step can read both from one tailor show --json call right after tailor deploy. Client secrets are never included. Credentials that cannot list OAuth2 clients, such as the workspace viewer role, get a warning and oauth2Clients: null, which sets that case apart from an application with no deployed OAuth2 clients.

Patch Changes

• #​2487 d160c86 Thanks @​dqn! - Declining a confirmation prompt now makes the command exit non-zero with a *_CANCELLED error code, as tailor deploy and tailor remove already did, instead of exiting 0 as if the operation had succeeded. This covers workspace delete / restore / prune, workspace user remove, organization folder delete, secret create / update / delete, secret vault delete, authconnection delete / revoke, tailordb truncate, and tailordb migration generate / set / sync / rebaseline. For example, tailor workspace delete reports WORKSPACE_DELETION_CANCELLED when the entered name does not match, and tailor tailordb migration generate still generates the other namespaces before reporting MIGRATION_GENERATE_CANCELLED for the ones whose breaking changes were declined. Confirmation prompts appear only in an interactive terminal, so runs with --yes, in CI, or with --json are unaffected. migrateGenerate() now rejects with MIGRATION_GENERATE_CANCELLED when its prompt is declined, instead of resolving or exiting the process.

• #​2484 7454455 Thanks @​dqn! - tailor init now exits non-zero when project scaffolding fails, instead of exiting 0. It reports INIT_FAILED when create @tailor-platform/sdk exits with a non-zero code or is terminated by a signal, and INIT_SPAWN_FAILED when the package manager cannot be started.

• #​2488 608b7eb Thanks @​dqn! - Argument errors now follow --json and TAILOR_JSON_OUTPUT. An unknown option or subcommand, or an option value that fails validation, was printed as plain text even when JSON output was requested, because it happened before the flag took effect. It is now reported as the usual JSON error envelope on stderr with the code INVALID_ARGUMENTS, for example {"error":{"code":"INVALID_ARGUMENTS","message":"Unknown flags: bogus"}}. --verbose now also applies to these errors, adding the stack trace to the envelope or to the plain-text output, as it does for other failures. Otherwise, output without JSON mode is unchanged.

• #​2506 69b3234 Thanks @​dqn! - List commands now say when --limit cut their output short. When more items exist than --limit allows, the list is followed by More results exist beyond --limit N. Raise --limit to see more. on stderr, so a caller can tell a complete list from a partial one; stdout, including --json output, is unchanged. This matters most for executor jobs, function logs, and workflow executions, which list 50 items unless --limit says otherwise.

• #​2492 46590a4 Thanks @​renovate! - fix(deps): update oxc

• #​2515 ef00996 Thanks @​renovate! - chore(deps): lock file maintenance

• #​2517 3220bc9 Thanks @​renovate! - fix(deps): update dependency rolldown to v1.2.12

• #​2483 ae6451e Thanks @​toiroakr! - tailor setup ci branch, tailor setup ci tag, and tailor setup ci preview accept --dir more than once. The generated workflow deploys every app to the same workspace in one multi-config run from the repository root, runs the generate check for each app directory (plus seed validation and the migration drift check on branch and tag workflows), and runs its jobs on changes under any of them. --name is required when --dir is repeated, and the root package.json must declare @tailor-platform/sdk. With --erd-preview, each TailorDB namespace is previewed from the app that owns it.

  tailor setup ci branch and tailor setup ci preview also accept --paths (repeatable) to run the generated jobs on changes outside the app directories, such as a frontend or shared packages. A pattern supports *, **, and a leading ! to exclude paths; other glob characters are rejected.

  Branch and preview workflows with an app directory other than the repository root no longer filter their on: triggers by paths. Branch workflows start on every pull request and push, preview workflows on every pull request, and a new tailor-changes job skips the plan, deploy, and preview jobs when nothing under the app directories (or --paths) changed. Skipped jobs report success, so these checks can be required in branch protection. If the tailor-changes job itself fails, those jobs fail instead of being skipped, so a required check cannot pass without them. setup remains a beta command, so this ships as an immediate change rather than going through a deprecation cycle.

  Branch workflows generated with --erd-preview now install the project dependencies before building the ERD preview, which the setup step does not do.

  The workflow template version is bumped, so tailor setup check reports every generated target as outdated; run tailor setup update to regenerate them. Branch and preview workflows whose --dir is not the repository root switch to the tailor-changes job described above, and branch workflows generated with --erd-preview get the new ERD matrix and install step. Other workflows regenerate identically. tailor setup update keeps every app directory and --paths pattern of a multi-directory target.

• #​2489 16175f6 Thanks @​toiroakr! - You can add environment: to a managed job that tailor setup ci generates without one (tailor-tag-guard, and the tailor-erd-preview* jobs from --erd-preview), so a step you added there can read that GitHub Environment's secrets, such as a token for installing dependencies from a private registry. tailor setup check no longer reports it as a hand edit, and re-running tailor setup ci keeps it. The environment: of tailor-plan, tailor-deploy, and the preview jobs still comes from --environment.

v2.24.0

Compare Source

Minor Changes

• #​2459 72e295b Thanks @​toiroakr! - When a resolver, executor, or workflow job fails to build with FORBIDDEN_RUNTIME_GLOBAL because it references a Node-only global such as process or Buffer, the error now names where the reference is: the file in your own code, or the installed package (code under node_modules). A reference from an installed package can be allowed with the new buildOptions.allowedRuntimeGlobals option of defineConfig(), keyed by package name, with the globals to allow or true for all of them — for example buildOptions: { allowedRuntimeGlobals: { "@ai-sdk/gateway": ["Buffer"] } } — once you have confirmed that the package's code referencing it never runs for your use. The error's suggestion shows the entry to add. buildOptions.allowedRuntimeGlobals has no effect on your own code.

• #​2463 f708521 Thanks @​toiroakr! - defineConfig() accepts buildOptions, which groups the settings that control how resolvers, executors, workflow jobs, and other functions are bundled: inlineSourcemap, logLevel, and allowedRuntimeGlobals. The top-level inlineSourcemap and logLevel still work but are deprecated and will be removed in v3; tailor upgrade moves them into buildOptions with the v3/define-config-build-options codemod. Setting the same option both at the top level and in buildOptions fails config validation instead of silently using one of them.

  export default defineConfig({
    name: "my-app",
    buildOptions: {
      inlineSourcemap: false,
      logLevel: "WARN",
    },
  });

Patch Changes

• #​2475 10ab737 Thanks @​toiroakr! - Generated deploy jobs now expose the deployed workspace as job outputs, so a job of your own can use needs: to run tests or deploy extra assets against it:

  • tailor setup ci preview: the tailor-preview-deploy job exposes workspace-id, workspace-name, and app-url of the per-PR workspace.
  • tailor setup ci branch and tailor setup ci tag: the tailor-deploy job exposes workspace-id and app-url.

  tailor setup check reports the template as outdated; run tailor setup update to regenerate every target.

• #​2464 978c332 Thanks @​renovate! - fix(deps): update secretlint monorepo to v13.0.6

• #​2465 d8222e4 Thanks @​renovate! - chore(deps): update dependency @​​types/node to v24.19.0

• #​2458 e982853 Thanks @​toiroakr! - Deploying a resolver, executor, or workflow no longer fails with FORBIDDEN_RUNTIME_GLOBAL for a Node-only global such as process that is only used after checking that it exists — for example if (typeof process !== "undefined") { ... process.env.FOO ... }, an early exit such as if (typeof process === "undefined") return; followed by process.env.FOO, or typeof process < "u" && process.emitWarning(message). A global used without such a check is still reported — for example the Buffer.from(...) inside @ai-sdk/gateway, which the Vercel AI SDK (ai) depends on.

• #​2457 be6ffb2 Thanks @​toiroakr! - Fix workflow.start() and job .start() calls that built and deployed but threw "workflow.start() is rewritten at build time and unavailable in the bundle" at runtime. These calls are now rewritten when:

  • the workflow file is imported through a tsconfig.json compilerOptions.paths alias (e.g. import workflow from "@/workflow/syncGLBalances")
  • the workflow is default-exported as the result of a helper function that calls createWorkflow() (e.g. export default module.workflows.syncGLBalances.create(mainJob)); wrapping the helper result in another createWorkflow({ ...helperResult, name: "..." }) call is no longer needed
  • the workflow file is imported as a namespace (import * as wf from "./workflows/sync"; wf.default.start(...))

  A .start() call on an import from a workflow file that still cannot be rewritten — such as a helper-created workflow exported under a named export — now fails the build instead of deploying code that throws at runtime. The runtime error for an unrewritten workflow.start() also names the workflow.

v2.23.0

Compare Source

Minor Changes

• #​2440 e2df6cf Thanks @​dqn! - tailor deploy now marks updates that show no configuration difference and are applied again only because the application's resources were last deployed with a different SDK version. The plan lists them with [forced by SDK version] and the summary counts them (12 to update (11 forced by SDK version)), so after an SDK upgrade you can tell them apart from real configuration changes. With --json, such changes carry forcedBySdkVersion: true and summary.forcedBySdkVersion counts them.

Patch Changes

• #​2442 4a974b1 Thanks @​dqn! - Fix the tailor deploy plan leaving out workflow execution policies: their changes are now listed in the Workflow section, and unmanaged or conflicting execution policies and applications now appear in the plan's warnings and owner conflicts, including --json output.

• #​2462 [551179a](https://redirec

[!IMPORTANT]
✂ PR body was truncated to here.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[jackchuka]

@tailor-platform/sdk 2.22.0 → 2.28.0 (minor). Additive; generate/typecheck/lint/format pass in all steps. Note CLI behavior changes (JSON output under AI agents, non-zero exit on declined prompt). Safe to merge.