You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mirrors
[apify/crawlee@cc01b18](apify/crawlee@cc01b18)
and
[apify/apify-sdk-js@a381728](apify/apify-sdk-js@a381728),
which did the same for Crawlee v4 and for the SDK on its `v4` branch.
## What changed
- `"type": "module"`, and the dual CJS+ESM build is gone: no more
`dist/index.mjs`, no `gen-esm-wrapper` postbuild step, and the
`import`/`require` export conditions collapse into `types` + `browser` +
`default`.
- Every relative import in `src/` and `test/` gets its `.js` extension,
which is the bulk of the diff. It follows from `"type": "module"` alone:
the files now emit as ESM, and ESM has no extension guessing or
directory-index lookup. `tsc` never rewrites specifiers, so dropping
them type-checks clean and then fails at runtime with
`ERR_MODULE_NOT_FOUND`. crawlee v4 and apify-sdk-js `v4` do the same.
- `require('../package.json')` in `getVersionData()` becomes a JSON
import attribute, with `resolveJsonModule` off so the emit doesn't sink
into `dist/src`.
- `__dirname` becomes `import.meta.dirname` in the test helpers and the
Vitest config.
- tsconfig pins `module`/`moduleResolution` to `NodeNext` and `target`
to `ESNext`, matching crawlee v4 and the SDK.
- `test/tsconfig.json` maps `apify-client` to `../src/index.ts` rather
than the `../src` directory. `nodenext` has no directory-index lookup,
so the directory form type-checked the tests against `dist`.
## The browser bundle is now an ES module
`dist/bundle.js` keeps its name and path, but rsbuild now emits it as an
ES module with named exports instead of UMD. The `Apify` global is gone:
load it with `<script type="module">` and `import { ApifyClient } from
'.../bundle.js'`. Under `"type": "module"` Node parses a `.js` file as
ESM anyway, and the UMD file in that spot broke `pnpm test:bundling` on
all four bundlers. The `apify-client/browser` subpath is unchanged.
## Breaking change
The client is pure ESM and ships no CommonJS build.
`require('apify-client')` still resolves on Node.js 22.12 and newer,
which loads an ES module through `require()` directly. Anywhere else,
CommonJS consumers have to switch to `import` or a dynamic `import()`.
Documented in the v3 upgrading guide, along with the bundle format
change.
*✍️ Drafted by Claude Code*
---------
Co-authored-by: Martin Adámek <banan23@gmail.com>
Copy file name to clipboardExpand all lines: docs/04_upgrading/upgrading_v3.md
+13Lines changed: 13 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,6 +9,19 @@ import ApiLink from '@theme/ApiLink';
9
9
10
10
This page summarizes the breaking changes when upgrading from v2 to v3 of `apify-client`.
11
11
12
+
## The package is now pure ESM
13
+
14
+
`apify-client` ships as an ES module. The CommonJS build is gone, along with the `dist/index.mjs` wrapper and the `require` condition in `exports`, so `import` is the supported way to load the client.
+ import { ApifyClient } from 'apify-client'; // v3
19
+
```
20
+
21
+
A CommonJS project can keep calling `require('apify-client')`: the client has no top-level `await`, and Node.js 22.12 and newer load an ES module through `require()` directly. On Node.js 22.0 to 22.11, `require()` of an ES module is still behind the `--experimental-require-module` flag, so use `import` there.
22
+
23
+
The browser bundle at `dist/bundle.js` is now an ES module instead of UMD, so it no longer defines an `Apify` global. Importing it, whether through a bundler or the `apify-client/browser` subpath, is unchanged. A classic `<script>` tag that read `Apify.ApifyClient` off the global has to become a `<script type="module">` that imports it instead. For details, see [Bundled environments](../02_concepts/05_bundled-environments.md).
24
+
12
25
## Argument validation switched from `ow` to `zod`
13
26
14
27
The client now validates the arguments you pass with [zod](https://zod.dev) instead of `ow`. This changes what gets thrown for invalid arguments, and tightens a few gaps `ow` used to let through silently.
0 commit comments