@zapier/zapier-sdk 0.101.2 → 0.102.0

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # @zapier/zapier-sdk
 
+## 0.102.0
+
+### Minor Changes
+
+- 52b672a: `@zapier/zapier-sdk` now installs `@zapier/kitcore` as a regular dependency instead of bundling a copy of it into its own build. Package managers pull it in automatically, so installs and imports keep working unchanged.
+
+  Three things this affects:
+  - Plugin, resolver, and formatter authors can import `definePlugin`, `defineMethod`, `createSdk`, and the rest from `@zapier/kitcore` directly, and those names stay re-exported from `@zapier/zapier-sdk`. To import it directly, add `@zapier/kitcore` to your own dependencies at the version `@zapier/zapier-sdk` depends on, because pnpm and Yarn PnP won't resolve an undeclared package, and a different version resolves to a second copy. Given a single resolved copy, the two import paths are the same module; across a duplicate install or a CJS/ESM split they aren't, so keep using the brand-based guards, `isCoreError` and `isCoreSignal`, for checks that have to survive that.
+  - If you **publish** a package that exports a plugin, its declarations decide whether you need `@zapier/kitcore` in your own dependencies. Left to inference, a `define*` result's type resolves to where kitcore declares it, so your published types name `@zapier/kitcore` and it has to be installable for anyone consuming them. Annotating the export with `MethodPlugin` and `LeafSummary` from `@zapier/zapier-sdk` keeps the reference on the SDK instead, and no kitcore dependency is required. Calling SDK methods, using its schemas, or building plugins you don't publish types for needs nothing either way.
+  - Browser bundlers pick up the `node:async_hooks` stub from `@zapier/kitcore`'s own `browser` field rather than `@zapier/zapier-sdk`'s. A bundler config that hand-aliased that import through `@zapier/zapier-sdk` may need updating.
+
+### Patch Changes
+
+- Updated dependencies [52b672a]
+  - @zapier/kitcore@0.17.1
+
 ## 0.101.2
 
 ### Patch Changes