| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat(integrations): refractor apple-app-store and use JWT method instead (#6955) ## Describe the problem and your solution - `apple-app-store` used a bespoke `APP_STORE` auth mode that has been broken since it was originally introduced in #1464: it signed a JWT and then POSTed it to `https://api.appstoreconnect.apple.com/v1/apps` expecting a token back (`createCredentialsFromURL`). But App Store Connect has no token-exchange endpoint — the signed JWT *is* the access token, used directly as the Bearer credential on every request — and `/v1/apps` is a GET-only "list apps" endpoint, not something you can trade a JWT against. `tokenResponse.token` was always `undefined`, so no connection using this auth mode could ever have worked. - I checked prod and there are zero active `apple-app-store` connections, so there's no migration path to worry about, this removes the broken auth mode outright instead of patching it, and uses an auth mode we are currently using with other providers. <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/6955?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> | 1 个月前 | |
fix(cli,dashboard): resolve symlinked integrations in pull and github links (#6632) The `nango pull` and `nango clone` commands would fail for symlinked integrations. Links to code in github would also be incorrect. This PR fixes that by: - Using the metadata already available in `flows.zero.yaml` to resolve symlinks server-side. - Doing a pre-fetch in github to check for symlinks in the CLI (it doesn't have access to the metadata, so we need to fetch). I did not try to over-optimize this, so the CLI does an extra call to github to see if it's a symlink. Keeps the diff way shorter. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/6632?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> | 2 个月前 | |
fix(cli,dashboard): resolve symlinked integrations in pull and github links (#6632) The `nango pull` and `nango clone` commands would fail for symlinked integrations. Links to code in github would also be incorrect. This PR fixes that by: - Using the metadata already available in `flows.zero.yaml` to resolve symlinks server-side. - Doing a pre-fetch in github to check for symlinks in the CLI (it doesn't have access to the metadata, so we need to fetch). I did not try to over-optimize this, so the CLI does an extra call to github to see if it's a symlink. Keeps the diff way shorter. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/6632?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> | 2 个月前 | |
feat(cli): add message when all files compile successfully in `nango dev` (#3908) <!-- Describe the problem and your solution --> ### Description We currently have no feedback for when all files compile successfully, leading to a confusing DX when the last thing you see is the last error you got. This PR adds this: <img width="803" alt="image" src="https://github.com/user-attachments/assets/4424d5e5-548c-49ff-ab7d-6cf8d3d42c3c" /> > Feel free to suggest another message To achieve this, I had to keep track of failed files and tweak how things were done. I believe I've fixed a couple bugs as a tangent. I'll add comments to the relevant sections with more details. <!-- Testing instructions (skip if just adding/editing providers) --> ### Testing Please checkout to the branch and run `nango dev` in a nango project. Break and fix typescript files and the config file, in mixed order, to see if the DX is looking good. The `No compilation errors.` message should only show up when everything is looking good, both with TS files as well as `nango.yaml`. | 1 年前 | |
chore: use modern tsconfig, node16 and nodenext (#4271) ## Changes - Use modern tsconfig, node16 and nodenext It's been the recommended setup for a while. The main big change is that extensions are required. I had already put in place the eslint rules, so it's mostly types import that are now failing. <!-- Summary by @propel-code-bot --> --- This PR migrates the repository to the modern TypeScript configuration using `moduleResolution: node16/nodenext`. The largest impact is the enforcement of explicit file extensions in all local import statements (notably, switching e.g. `import './foo'` to `import './foo.js'`), affecting TypeScript, JavaScript, and type-only imports across CLI, frontend, backend, persistence layers, scheduler, and tests. Additional adjustments include some fixes for ESM/CJS interop and `@ts-expect-error` usage for older libraries whose types are out-of-date under this resolution strategy. No business logic or runtime functional changes are introduced-changes are restricted to code style, imports, test fixtures, and developer workflow. **Key Changes:** • Adopts modern TypeScript configuration: tsconfig with node16/nodenext module resolution. • Refactors all internal imports to include explicit file extensions (.js). • Updates type-only imports to comply with new import rules. • Adds or adjusts @ts-expect-error comments for packages with known TS resolution/type issues (e.g., AJV, Conf). • Minor reordering of imports and addition of missing type imports. • Developer workflow/documentation changes-internal import patterns now require extensions. **Affected Areas:** • TypeScript (tsconfig) configuration • Import statements across CLI, server, scheduler, frontend, runner, fleet, logs, persist • Test files and fixtures • Type import statements • Developer build and workflow practices *This summary was automatically generated by @propel-code-bot* | 1 年前 | |
chore(lint): move import sorting to Prettier (#6582) ## Problem We're replacing ESLint with oxlint (NAN-5769). oxlint has no `import/order` equivalent — its maintainers deliberately defer import sorting to the formatter — so import ordering needs a new home before the linter swap. ## Solution Move import ordering to Prettier via `@ianvs/prettier-plugin-sort-imports`, configured to replicate the existing `import/order` grouping exactly: builtins → external → `@nangohq/*` → `@/*` + relative → type imports, blank lines between groups, alphabetised within. The `import/order` rule (and its now-pointless migrations override) is removed from the ESLint config. Doing this first — while ESLint still runs — means the change is verifiable in isolation: format-on-save behaviour is identical for developers, and CI's existing `prettier --check` + ESLint both still gate it. Two commits: - `chore(lint): move import sorting to Prettier` — the plugin + config (this is the one to actually review) - `style: sort imports across the codebase` — the mechanical 489-file reformat (skim only; import order changes only, no logic) Part of NAN-5769. Sub-issue: NAN-5808. ## Testing - `eslint . --quiet` passes clean (exit 0) on the reformatted code - Reformat is purely mechanical — only import grouping/order changed - Spot-checked plugin output against the old `import/order` grouping; identical | 2 个月前 | |
chore(lint): move import sorting to Prettier (#6582) ## Problem We're replacing ESLint with oxlint (NAN-5769). oxlint has no `import/order` equivalent — its maintainers deliberately defer import sorting to the formatter — so import ordering needs a new home before the linter swap. ## Solution Move import ordering to Prettier via `@ianvs/prettier-plugin-sort-imports`, configured to replicate the existing `import/order` grouping exactly: builtins → external → `@nangohq/*` → `@/*` + relative → type imports, blank lines between groups, alphabetised within. The `import/order` rule (and its now-pointless migrations override) is removed from the ESLint config. Doing this first — while ESLint still runs — means the change is verifiable in isolation: format-on-save behaviour is identical for developers, and CI's existing `prettier --check` + ESLint both still gate it. Two commits: - `chore(lint): move import sorting to Prettier` — the plugin + config (this is the one to actually review) - `style: sort imports across the codebase` — the mechanical 489-file reformat (skim only; import order changes only, no logic) Part of NAN-5769. Sub-issue: NAN-5808. ## Testing - `eslint . --quiet` passes clean (exit 0) on the reformatted code - Reformat is purely mechanical — only import grouping/order changed - Spot-checked plugin output against the old `import/order` grouping; identical | 2 个月前 | |
feat(dryrun-diagnostics): add diagnostics service for dryrun (#4987) <!-- Describe the problem and your solution --> <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- Summary by @propel-code-bot --> --- **Add `--diagnostics` flag with CPU/Memory monitoring to `dryrun` command** The PR introduces an opt-in lightweight diagnostics facility for the CLI `dryrun` path. When the new `--diagnostics` flag is present, a `DiagnosticsMonitor` is instantiated before user code executes and stopped afterwards, producing a formatted summary of average and peak RSS/heap/external memory plus CPU utilisation. The feature is fully plumbed through the public `DryRunService`, its private `runScript()` helper, and the CLI entry-point without altering default behaviour when the flag is omitted. <details> <summary><strong>Key Changes</strong></summary> • Created `packages/cli/lib/services/diagnostics-monitor.service.ts` implementing `DiagnosticsMonitor`, adaptive 50-100 ms sampling, bounded sample buffer (`MAX_SAMPLES = 5000`), statistics calculators and `formatDiagnostics()` pretty printer • Extended `RunArgs`, `runScript()` and `DryRunService.run()` to accept optional `diagnostics?: boolean` and to start/stop the monitor around script execution • Added CLI flag registration in `packages/cli/lib/index.ts` for top-level and `dryrun` sub-command • Inserted report printing in `finally` blocks so summary always appears even on error paths • Addressed review feedback by bounding sample array growth </details> <details> <summary><strong>Affected Areas</strong></summary> • `packages/cli/lib/services/diagnostics-monitor.service.ts` • `packages/cli/lib/services/dryrun.service.ts` • `packages/cli/lib/index.ts` </details> --- *This summary was automatically generated by @propel-code-bot* | 9 个月前 | |
feat(cli): build and send json-schema per function (#5572) > Function aka "flow", "sync_config" We currently generate a "global" json schema with all the models in the integration folders and save it to `schema.json`. When deploying / generating docs / dry-running, we load that big schema and use it as the source of truth. We send the full json-schema for deploying, and let the server filter the schemas for each function (aka. sync_config, flow). Furthermore, we take a very convoluted path to generate `schema.json`: - Convert zod schemas to `NangoModel` - Use `NangoModel` to generate `schema.ts` - Use `ts-to-json-schema-generator` to generate `schema.json` from `schema.ts` In my previous PR, I made the server accept function-level json-schemas. Each function can now be sent with it's own json-schema, as opposed to a single top-level json-schema in `POST /sync/deploy`. This PR: - Keeps the generation of `schema.ts` and `schema.json` AS IS (adds a deprecation notice comment on `schema.ts`) - Updates zod versions in the `cli` and `runner-sdk` packages to v4.3.6 (currently latest) - Also updates zod version in `cli/example/package.json`. This is what will make our customers packages be updated as soon as a cli command is run. - Leverages `z.toJsonSchema` (introduced in zod v4) to generate json-schemas directly from the zod schemas. - Adds the json-schemas to each function in the payload. - Stops sending top-level json-schema with all models - Modifies dry-run and generate:docs to use these function-level json-schemas instead of `schema.json`. - These new json-schemas are generated and kept in-memory. They don't generate any artifacts. Every run of `deploy`, `dry-run` and `generate:docs` will re-generate them in-memory for use. The source is the compiled `cjs` files, and not the typescript files themselves. <!-- Summary by @propel-code-bot --> --- It also adjusts parsing and validation types to allow optional per-function json_schema fields and updates related tests/snapshots to match the new schema format expectations. --- *This summary was automatically generated by @propel-code-bot* | 5 个月前 | |
fix(cli-generate-docs): handle optional props (#4465) <!-- Describe the problem and your solution --> <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- Summary by @propel-code-bot --> --- **cli-generate-docs: Properly Handles Optional Properties in modelToJson** This PR updates the modelToJson function within docs.service.ts to correctly distinguish between required and optional properties when generating JSON schema examples for documentation. Optional properties in object schemas are now suffixed with a '?' in the output, and the logic for tracking and propagating 'required' fields through nested schemas (, arrays, unions) has been refactored. Test coverage was also updated to assert correct handling of required vs. optional properties. <details> <summary><strong>Key Changes</strong></summary> • Added the optional `required` argument to `modelToJson`, defaulting to []. • Object properties that are not required are now displayed with a `?` suffix in output. • Recursive invocations of `modelToJson` (for , arrays, unions) now accept and pass the `required` array appropriately. • Updated handling of object properties in `modelToJson` to respect `required` from the ``JSON`` schema. • Unit tests updated to expect optional properties (and nested ones) to have correct `?` key notation. </details> <details> <summary><strong>Affected Areas</strong></summary> • packages/cli/lib/services/docs.service.ts (`modelToJson` function) • packages/cli/lib/services/docs.service.unit.test.ts (tests for `modelToJson`) </details> --- *This summary was automatically generated by @propel-code-bot* | 1 年前 | |
chore(lint): move import sorting to Prettier (#6582) ## Problem We're replacing ESLint with oxlint (NAN-5769). oxlint has no `import/order` equivalent — its maintainers deliberately defer import sorting to the formatter — so import ordering needs a new home before the linter swap. ## Solution Move import ordering to Prettier via `@ianvs/prettier-plugin-sort-imports`, configured to replicate the existing `import/order` grouping exactly: builtins → external → `@nangohq/*` → `@/*` + relative → type imports, blank lines between groups, alphabetised within. The `import/order` rule (and its now-pointless migrations override) is removed from the ESLint config. Doing this first — while ESLint still runs — means the change is verifiable in isolation: format-on-save behaviour is identical for developers, and CI's existing `prettier --check` + ESLint both still gate it. Two commits: - `chore(lint): move import sorting to Prettier` — the plugin + config (this is the one to actually review) - `style: sort imports across the codebase` — the mechanical 489-file reformat (skim only; import order changes only, no logic) Part of NAN-5769. Sub-issue: NAN-5808. ## Testing - `eslint . --quiet` passes clean (exit 0) on the reformatted code - Reformat is purely mechanical — only import grouping/order changed - Spot-checked plugin output against the old `import/order` grouping; identical | 2 个月前 | |
chore(lint): move import sorting to Prettier (#6582) ## Problem We're replacing ESLint with oxlint (NAN-5769). oxlint has no `import/order` equivalent — its maintainers deliberately defer import sorting to the formatter — so import ordering needs a new home before the linter swap. ## Solution Move import ordering to Prettier via `@ianvs/prettier-plugin-sort-imports`, configured to replicate the existing `import/order` grouping exactly: builtins → external → `@nangohq/*` → `@/*` + relative → type imports, blank lines between groups, alphabetised within. The `import/order` rule (and its now-pointless migrations override) is removed from the ESLint config. Doing this first — while ESLint still runs — means the change is verifiable in isolation: format-on-save behaviour is identical for developers, and CI's existing `prettier --check` + ESLint both still gate it. Two commits: - `chore(lint): move import sorting to Prettier` — the plugin + config (this is the one to actually review) - `style: sort imports across the codebase` — the mechanical 489-file reformat (skim only; import order changes only, no logic) Part of NAN-5769. Sub-issue: NAN-5808. ## Testing - `eslint . --quiet` passes clean (exit 0) on the reformatted code - Reformat is purely mechanical — only import grouping/order changed - Spot-checked plugin output against the old `import/order` grouping; identical | 2 个月前 | |
feat: add CreateFunction definition (#6664) Also remove the recent changes made around createWebhook. They will be folded and reintroduced as part of the function primitive initiative `function` definition types are in https://github.com/NangoHQ/nango/pull/6664/changes#diff-cedceb6eb8af423d2de17f68fed59bd218cf3c5029655359b4361d444c733256 The rest is reverting support for `createWebhook` in `runner-sdk` and `cli` <!-- Describe the problem and your solution --> <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/6664?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> | 2 个月前 | |
chore(lint): move import sorting to Prettier (#6582) ## Problem We're replacing ESLint with oxlint (NAN-5769). oxlint has no `import/order` equivalent — its maintainers deliberately defer import sorting to the formatter — so import ordering needs a new home before the linter swap. ## Solution Move import ordering to Prettier via `@ianvs/prettier-plugin-sort-imports`, configured to replicate the existing `import/order` grouping exactly: builtins → external → `@nangohq/*` → `@/*` + relative → type imports, blank lines between groups, alphabetised within. The `import/order` rule (and its now-pointless migrations override) is removed from the ESLint config. Doing this first — while ESLint still runs — means the change is verifiable in isolation: format-on-save behaviour is identical for developers, and CI's existing `prettier --check` + ESLint both still gate it. Two commits: - `chore(lint): move import sorting to Prettier` — the plugin + config (this is the one to actually review) - `style: sort imports across the codebase` — the mechanical 489-file reformat (skim only; import order changes only, no logic) Part of NAN-5769. Sub-issue: NAN-5808. ## Testing - `eslint . --quiet` passes clean (exit 0) on the reformatted code - Reformat is purely mechanical — only import grouping/order changed - Spot-checked plugin output against the old `import/order` grouping; identical | 2 个月前 | |
feat: add CreateFunction definition (#6664) Also remove the recent changes made around createWebhook. They will be folded and reintroduced as part of the function primitive initiative `function` definition types are in https://github.com/NangoHQ/nango/pull/6664/changes#diff-cedceb6eb8af423d2de17f68fed59bd218cf3c5029655359b4361d444c733256 The rest is reverting support for `createWebhook` in `runner-sdk` and `cli` <!-- Describe the problem and your solution --> <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/6664?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> | 2 个月前 | |
fix(cli): init default to zero yaml (#4303) ## Changes - init default to zero yaml Could not remove the old code since it's still used in the CI. All the rest should still be retro-compatible until EOL. - Add new option to only copy files so that the CI works <!-- Summary by @propel-code-bot --> --- This PR refactors the Nango CLI's 'init' command, making the zero-yaml (TypeScript-based project structure) the default for initializing projects and removing legacy initialization code. The legacy '--zero' flag and related code paths are deprecated; a new '--copy' option is added to allow CI or advanced users to initialize projects by copying template files only (skipping dependency installation and compile steps). Associated supporting code (types, verification, SDK helpers), related test and workflow scripts, and ESLint configuration have been updated for compatibility and clearer separation between legacy and new behaviors. <details> <summary><strong>Key Changes</strong></summary> • Removed all legacy CLI init code and related unit tests (init.service.ts, init.service.unit.ts). • Refactored the 'init' command: zero yaml is now always used, '--zero' flag removed. • Added a new '--copy' option to 'nango init' to just copy template files (primarily for CI). • Updated index.ts, types, verificationService, and related CLI code for new logic. • CI workflow changed to use 'nango init --copy' and then run explicit npm install/compile. • ESLint overrides for tests narrowed to scripts/ directory. • Removed type and CLI references to legacy paths and flags. </details> <details> <summary><strong>Affected Areas</strong></summary> • CLI core (index.ts, types.ts, zeroYaml/init.ts) • Verification and init services • CLI test suite and templates • CI workflow (.github/workflows/cli-verification.yaml) • ESLint configuration </details> *This summary was automatically generated by @propel-code-bot* | 1 年前 | |
feat(cli): support mtls (#7325) ## Summary - Let the CLI present a client certificate when talking to a self-hosted Nango API behind mTLS, so customers no longer have to disable mTLS for `deploy` / `dryrun` / `pull`. - Configure it with `NANGO_CLI_TLS_CERT` (path to a PEM). A file that contains both cert and key is enough; `NANGO_CLI_TLS_KEY` / `NANGO_CLI_TLS_CA` cover split files and a private CA. - The same TLS agent is used on every CLI-to-API path (axios, fetch, and the Node SDK). Invalid cert/key pairs fail at load time. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/7325?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> | 6 天前 | |
chore(lint): move import sorting to Prettier (#6582) ## Problem We're replacing ESLint with oxlint (NAN-5769). oxlint has no `import/order` equivalent — its maintainers deliberately defer import sorting to the formatter — so import ordering needs a new home before the linter swap. ## Solution Move import ordering to Prettier via `@ianvs/prettier-plugin-sort-imports`, configured to replicate the existing `import/order` grouping exactly: builtins → external → `@nangohq/*` → `@/*` + relative → type imports, blank lines between groups, alphabetised within. The `import/order` rule (and its now-pointless migrations override) is removed from the ESLint config. Doing this first — while ESLint still runs — means the change is verifiable in isolation: format-on-save behaviour is identical for developers, and CI's existing `prettier --check` + ESLint both still gate it. Two commits: - `chore(lint): move import sorting to Prettier` — the plugin + config (this is the one to actually review) - `style: sort imports across the codebase` — the mechanical 489-file reformat (skim only; import order changes only, no logic) Part of NAN-5769. Sub-issue: NAN-5808. ## Testing - `eslint . --quiet` passes clean (exit 0) on the reformatted code - Reformat is purely mechanical — only import grouping/order changed - Spot-checked plugin output against the old `import/order` grouping; identical | 2 个月前 | |
chore: eslint pass on import order 3 (#4296) ## Changes - Last pass to activate import order rules we were definitely not getting there manually <!-- Summary by @propel-code-bot --> --- This PR performs a comprehensive, automated update to the import statements across the entire codebase to fully enforce ESLint's import/order rules, as well as related import linting conventions. The 'import/order' rule in the ESLint configuration is raised from 'warn' to 'error', and many TypeScript and JavaScript source files are modified to reorder, group, and separate import/type import statements accordingly. No business logic or functional behavior is changed; all modifications are organizational and related to linting compliance. <details> <summary><strong>Key Changes</strong></summary> • Systematic reordering and grouping of import and type import statements in all TypeScript and JavaScript files, aligning with stricter ESLint import/order rules. • ESLint configuration (eslint.config.mjs) updated: 'import/order' set to 'error' and related rules adjusted; minor tuning to linting options for clarity and performance. • No code logic, functionality, or documentation changes introduced-scope is strictly import organization and enforcement of lint rules. </details> <details> <summary><strong>Affected Areas</strong></summary> • All source code files (.ts/.js) across the repository • eslint.config.mjs (ESLint config for import/style rules) </details> *This summary was automatically generated by @propel-code-bot* | 1 年前 | |
feat(cli): minimal support for function compilation (#6738) Compile minimal functions (manually triggered, no-data). Deploy command ignores them for now. Added experimental warning <!-- Describe the problem and your solution --> <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/6738?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> | 1 个月前 | |
feat(cli): deploy functions (#7068) Migrating from legacy to native functions is gonna require the backend to own and reconcile the state of the deployed code (and their potential models) and potentially move from sync/actions to functions. To simplify, we for now don't allow mixed deployment (ie: containing both legacy and native functions) so we can start beta test functions in isolation. Migrations will come later. <!-- Describe the problem and your solution --> <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/7068?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> | 27 天前 | |
feat(syncs): Expose listRecords for use in syncs (#5676) <!-- Describe the problem and your solution --> listRecords needs to be exposed in sync code to allow for [two-layer sync for MobileFirst](https://linear.app/nango/issue/NAN-4939/themobilefirstco-attio-real-time-syncing) to reduce sync load <!-- Issue ticket number and link (if applicable) --> [NAN-5073: Expose listRecords for use in syncs](https://linear.app/nango/issue/NAN-5073/expose-listrecords-for-use-in-syncs) <!-- Testing instructions (skip if just adding/editing providers) --> In a sample integrations repo: - Point towards local copy of CLI/runner SDK - Create sync that uses newly exposed nango.listRecords function - Compile and dry run sync <!-- Summary by @propel-code-bot --> --- **Expose `listRecords` async iterator in sync runners** This PR introduces a new `listRecords` async iterator to sync execution paths, enabling scripts to iterate persisted records page-by-page. The change is wired through the runner SDK, CLI sync runner, type definitions, telemetry allowlists, and persist client request handling, with abort checks during iteration and batching. Supporting updates include a shared `fetchRecordsPage` helper for `getRecordsByIds`, optional `limit` propagation to the persist API, parser/compile validations, mock updates, and expanded unit tests covering abort behavior and multi-page cursor flows. --- *This summary was automatically generated by @propel-code-bot* | 5 个月前 | |
feat(cli): support mtls (#7325) ## Summary - Let the CLI present a client certificate when talking to a self-hosted Nango API behind mTLS, so customers no longer have to disable mTLS for `deploy` / `dryrun` / `pull`. - Configure it with `NANGO_CLI_TLS_CERT` (path to a PEM). A file that contains both cert and key is enough; `NANGO_CLI_TLS_KEY` / `NANGO_CLI_TLS_CA` cover split files and a private CA. - The same TLS agent is used on every CLI-to-API path (axios, fetch, and the Node SDK). Invalid cert/key pairs fail at load time. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/7325?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> | 6 天前 | |
fix(cli,dashboard): resolve symlinked integrations in pull and github links (#6632) The `nango pull` and `nango clone` commands would fail for symlinked integrations. Links to code in github would also be incorrect. This PR fixes that by: - Using the metadata already available in `flows.zero.yaml` to resolve symlinks server-side. - Doing a pre-fetch in github to check for symlinks in the CLI (it doesn't have access to the metadata, so we need to fetch). I did not try to over-optimize this, so the CLI does an extra call to github to see if it's a symlink. Keeps the diff way shorter. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/6632?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> | 2 个月前 | |
feat(proxy): add a flag in the proxyConfig to enable forwarding header on redirect (#5668) ## Describe the problem and your solution - This feature was originally added to support dayforce, which required authorization headers to be forwarded during redirects. We now provide a flag in `proxyConfig` that allows customers to disable header forwarding for redirects. - Use case: In hibob, when users request file downloads, the API returns a HiBob download URL that issues a HTTP redirect to an amazon s3 signed url. Passing the Authorization header to this redirected URL results in an error, as signed urls are pre-authorized and do not accept additional authorization headers. <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- Summary by @propel-code-bot --> --- **Add `forwardHeadersOnRedirect` proxy flag with metrics and provider support** This PR adds a configurable `forwardHeadersOnRedirect` option to proxy configuration, allowing callers to disable forwarding headers when `axios` follows redirects while preserving the existing default behavior. The flag is wired through public proxy headers, internal proxy configuration construction, `axios` setup, and type definitions, with a new `PROXY_REDIRECT` metric emitted on redirects. Provider schema validation and provider configs are extended to support a provider-level default (`forward_headers_on_redirect`), and SDK/CLI surfaces are updated to send/ignore the new header. Unit tests and snapshots are adjusted to reflect the new configuration flow and `axios` behavior. --- *This summary was automatically generated by @propel-code-bot* | 5 个月前 | |
feat(proxy): meter transferred bytes via transport (#6078) <!-- Describe the problem and your solution --> Previous metering was partial as it only metered buffered responses. Responses that were chunked, content-encoded or had Content-Disposition:attachment|inline were entirely bypassed. Further, the metering only counted decompressed body bytes, which is not a suitable approach to capture inputs for billing. The introduced transport wraps follow-redirect and snapshots socket bytesRead/Written deltas per redirect hop; the proxy request object accumulates the bytes across hops and fires the onBytes callback if set. Wired both the server proxy and runner SDK paths. Reporpused metrics: - PROXY_INCOMING_PAYLOAD_SIZE_BYTES → PROXY_REQUEST_SIZE_IN_BYTES - PROXY_OUTGOING_PAYLOAD_SIZE_BYTES → PROXY_RESPONSE_SIZE_IN_BYTES This is the first phase of the data transfer metering plan: instrument to observe in DataDog and then productize it by sending the data to ClickHouse/Orb. | 3 个月前 | |
feat(cli): support mtls (#7325) ## Summary - Let the CLI present a client certificate when talking to a self-hosted Nango API behind mTLS, so customers no longer have to disable mTLS for `deploy` / `dryrun` / `pull`. - Configure it with `NANGO_CLI_TLS_CERT` (path to a PEM). A file that contains both cert and key is enough; `NANGO_CLI_TLS_KEY` / `NANGO_CLI_TLS_CA` cover split files and a private CA. - The same TLS agent is used on every CLI-to-API path (axios, fetch, and the Node SDK). Invalid cert/key pairs fail at load time. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/7325?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> | 6 天前 | |
feat(cli): support mtls (#7325) ## Summary - Let the CLI present a client certificate when talking to a self-hosted Nango API behind mTLS, so customers no longer have to disable mTLS for `deploy` / `dryrun` / `pull`. - Configure it with `NANGO_CLI_TLS_CERT` (path to a PEM). A file that contains both cert and key is enough; `NANGO_CLI_TLS_KEY` / `NANGO_CLI_TLS_CA` cover split files and a private CA. - The same TLS agent is used on every CLI-to-API path (axios, fetch, and the Node SDK). Invalid cert/key pairs fail at load time. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/7325?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> | 6 天前 | |
chore(lint): move import sorting to Prettier (#6582) ## Problem We're replacing ESLint with oxlint (NAN-5769). oxlint has no `import/order` equivalent — its maintainers deliberately defer import sorting to the formatter — so import ordering needs a new home before the linter swap. ## Solution Move import ordering to Prettier via `@ianvs/prettier-plugin-sort-imports`, configured to replicate the existing `import/order` grouping exactly: builtins → external → `@nangohq/*` → `@/*` + relative → type imports, blank lines between groups, alphabetised within. The `import/order` rule (and its now-pointless migrations override) is removed from the ESLint config. Doing this first — while ESLint still runs — means the change is verifiable in isolation: format-on-save behaviour is identical for developers, and CI's existing `prettier --check` + ESLint both still gate it. Two commits: - `chore(lint): move import sorting to Prettier` — the plugin + config (this is the one to actually review) - `style: sort imports across the codebase` — the mechanical 489-file reformat (skim only; import order changes only, no logic) Part of NAN-5769. Sub-issue: NAN-5808. ## Testing - `eslint . --quiet` passes clean (exit 0) on the reformatted code - Reformat is purely mechanical — only import grouping/order changed - Spot-checked plugin output against the old `import/order` grouping; identical | 2 个月前 | |
feat(cli): Clear mocks in generated sync tests (#5605) <!-- Describe the problem and your solution --> <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- Summary by @propel-code-bot --> --- **Improve generated sync test template mock isolation** Updates the sync test template to create a fresh `NangoSyncMock` per test, add `afterEach` cleanup for `vitest` mocks, and add clearer spy normalization for batch save/delete comparisons. Adjusts unit test expectations in `packages/cli/lib/services/test.service.unit.cli-test.ts` to match the new template output. --- *This summary was automatically generated by @propel-code-bot* | 5 个月前 | |
docs: update docs structure and verify links (#6013) ## Summary - Flatten and reorganize the Reference section into the requested structure: Frontend, Backend, and Functions. - Move Reference files to match the nav: `reference/frontend/frontend-sdk`, `reference/backend/http-api`, `reference/backend/backend-sdk`, and `reference/functions/{functions-cli,functions-sdk}`. - Move API configuration out of `reference/` into `integrations/api-configuration`, where it is linked from the APIs & Integrations tab. - Rename guide files so slugs match page titles, move sync docs under `guides/functions/syncs`, and unnest the platform proxy page. - Update affected Nango docs links across docs, app/CLI doc URLs, provider metadata, agent docs, and generator/source files. - Update snippet generation logic, but intentionally exclude generated docs output from this PR so the diff stays reviewable. - Add docs agent guidance that link-maintenance PRs must only edit links and must run targeted Prettier checks when code URLs change. ## Redirect note - Generated integration/API pages and generated snippets are intentionally unchanged in this PR. - Because those generated files still contain legacy docs paths, `docs.json` keeps redirect coverage for now; pruning redirects before the separate generation PR would break current generated docs links. - Redirect destinations were normalized to current canonical pages and do not include `#` anchors or query params, since Mintlify redirects do not support those. ## Link audit - Checked Nango docs links across the codebase, not just `docs/`. - Current result: 0 invalid docs paths and 0 invalid redirect destinations. - Some legacy generated-output links are still redirect-covered by design and should disappear in the separate generation PR. ## Validation - Custom docs route/redirect audit: passes - Exact-content check for moved Reference files: passes, only expected URL rewrites - Generated output directories/pages have no net diff against the previous PR commit - `npx prettier --check` on changed code files - `git diff --check` Created by Codex. | 4 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 9 个月前 | ||
| 5 个月前 | ||
| 1 年前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 1 年前 | ||
| 6 天前 | ||
| 2 个月前 | ||
| 1 年前 | ||
| 1 个月前 | ||
| 27 天前 | ||
| 5 个月前 | ||
| 6 天前 | ||
| 2 个月前 | ||
| 5 个月前 | ||
| 3 个月前 | ||
| 6 天前 | ||
| 6 天前 | ||
| 2 个月前 | ||
| 5 个月前 | ||
| 4 个月前 |