| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix: upgrade to zod v4 (#4328) ## Changes - Upgrade zod to v4 It was a bit more involved; they changed the import strategy, some props, error messages, deprecated a bunch of methods - Upgrade zero yaml to v4 Since Zod is now part of our API, we need to be careful about updates like this. Thankfully, it's still mostly compatible. I wrote a little helper that syncs the package.json dependencies version so we keep people in sync whether they like it or not :D ## 🧪 Tests I tested zod v4 with `npm install -g nango@0.63.1-beta.1` and staging Locally: run the dashboard, call some endpoints, deploy your scripts, etc. <!-- Summary by @propel-code-bot --> --- This PR performs a full upgrade from Zod v3 to v4 across the Nango monorepo, affecting core CLI, backend jobs, Connect UI, examples, test suites, and related documentation. All existing imports and usages of Zod are refactored for the new namespace import pattern and breaking API changes in v4. CLI and migration tooling is enhanced to ensure that user projects remain in sync with the required Zod version via a new helper and stricter dependency enforcement during initialization, migration, and dev workflows. Type conversion utilities, test snapshots, and example scripts are adapted for Zod v4 compatibility, and accompanying documentation reflects the updated API. <details> <summary><strong>Key Changes</strong></summary> • Upgrade all Zod packages/dependencies from v3 to v4 and update all import statements to 'import * as z from "zod"'. • Adjust all usage sites for Zod breaking changes (e.g., schema/property APIs, type usage). • Introduce helper utility (checkAndSyncPackageJson) and associated workflow to strictly sync Zod version in user projects' package.json. • Update CLI tooling, migrations, zeroYaml, and example projects to enforce required Zod version. • Update Connect UI and frontend to use new Zod APIs and bump related peer dependencies (e.g., react-hook-form, Vite). • Adapt test snapshots, test fixtures, and CLI migration/unit tests for Zod v4 compatibility. • Adjust and document code samples, migration guides, and all references to Zod usage/patterns. </details> <details> <summary><strong>Affected Areas</strong></summary> • CLI core and migration code • Backend job routes and validation logic • Connect UI frontend and form handling • Package/dependency management for CLI-generated projects • Type conversion utilities between Zod and internal model fields • Test fixtures, snapshots, and unit tests • User and developer documentation, migration guides </details> *This summary was automatically generated by @propel-code-bot* | 1 年前 | |
feat(cli-create-command): new create command for zeroyaml in the cli (#4892) <!-- Describe the problem and your solution --> ``` ➜ nango-cli-create-test npx nango create --sync google-calendar calendar-events Created sync: /Users/khaliqgant/Sites/nango-cli-create-test/google-calendar/syncs/calendar-events.ts ➜ nango-cli-create-test npx nango create --action google-calendar create-event Created action: /Users/khaliqgant/Sites/nango-cli-create-test/google-calendar/actions/create-event.ts ➜ nango-cli-create-test pulumi up --replace urn:pulumi:prod::prpm-infra::aws:rds/parameterGroup:ParameterGroup::prpm-prod-db-params ➜ nango-cli-create-test npx nango create --on-event google-calendar validate-credentials ``` <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- Summary by @propel-code-bot --> --- **Add `nango create` zero-yaml scaffolding command to CLI** Introduces a new `create` sub-command to the Nango CLI that generates boilerplate TypeScript files (`sync`, `action`, or `on-event`) for zero-yaml integrations. A generation service (`function-create.service.ts`) copies a template, writes it to the correct directory structure, and appends an import to `index.ts`. Supporting constants, ESLint ignores, example comments and CLI wiring are added. <details> <summary><strong>Key Changes</strong></summary> • New service `packages/cli/lib/services/function-create.service.ts` that handles template selection, directory creation, file write and `index.ts` import append • Three scaffolding templates added under `packages/cli/templates/` (`sync.ts`, `action.ts`, `on-event.ts`) • CLI registration of `create` command with `--sync`, `--action`, `--on-event` flags and integration/name args in `packages/cli/lib/index.ts` • Added `templateFolder` constant to `packages/cli/lib/zeroYaml/constants.ts` • Updated `eslint.config.mjs` ignore list to skip `packages/cli/templates/` • Minor comment tweak in example file `packages/cli/example/github/on-events/pre-connection-deletion.ts` </details> <details> <summary><strong>Affected Areas</strong></summary> • `packages/cli/lib/services/function-create.service.ts` • `packages/cli/lib/index.ts` (command registration) • `packages/cli/lib/zeroYaml/constants.ts` • `packages/cli/templates/*` • `eslint.config.mjs` </details> --- *This summary was automatically generated by @propel-code-bot* | 10 个月前 | |
feat: make track deletes work across execution (#5517) The track deletes features currently assume the entire dataset is being fetched/saved within a single execution. Which means it isn't compatible with checkpoints and fetching/saving across multiple executions. To solve this problem, this PR is introducing a way to explicitly define the start and the end of the track deletes interval, storing the starting point in a special checkpoint that survive across executions, instead of assuming the start is always the beginning of the current execution cc @bastienbeurier to agree on the naming `trackDeletesStart/trackDeletesEnd` ex: ``` exec: async (nango) => { await nango.trackDeletesStart('MyModel'); ... await nango.batchSave([...], 'MyModel'); ... const deleted = await nango.trackDeletesEnd('MyModel'); } ``` <!-- Summary by @propel-code-bot --> --- The runner stores a per-model delete-window checkpoint keyed off the sync checkpoint and, when the window closes, uses it to invoke deletion of outdated records before clearing the checkpoint. <details> <summary><strong>Key Changes</strong></summary> • Added `trackDeletesStart`/`trackDeletesEnd` to `NangoSyncBase` and `NangoSyncRunner`, with per-model checkpoint keys and `deleteOutdatedRecords` using stored `syncJobId` • Refactored `Checkpointing` in `packages/runner/lib/sdk/checkpointing.ts` to manage per-key state and accept `key` arguments for checkpoint operations • Expanded CLI parser/compiler validations to track `trackDeletes` calls per model and enforce ordering around `batchSave` • Updated docs and examples to use `trackDeletesStart`/`trackDeletesEnd` and mark `deleteRecordsFromPreviousExecutions` as deprecated • Reset behavior in `packages/shared/lib/clients/orchestrator.ts` now hard-deletes all checkpoints with a key prefix </details> <details> <summary><strong>Possible Issues</strong></summary> • A run that calls `trackDeletesStart` but exits before `trackDeletesEnd` will leave the delete-window checkpoint in place for future runs • The per-key `stateByKey` map in `Checkpointing` is not pruned, which could grow in long-lived processes with many dynamic keys • Full reset now returns an error if `hardDeleteCheckpoints` fails, which could block user-initiated resets </details> --- *This summary was automatically generated by @propel-code-bot* | 6 个月前 |