docs: document slim Docker images and package manager setup - #2954
docs: document slim Docker images and package manager setup#2954vladfrangu wants to merge 3 commits into
Conversation
github-actions
Bot
added
the
t-tooling
|
✅ Preview for this PR (commit |
honzajavorek
left a comment
honzajavorek
left a comment
There was a problem hiding this comment.
Thanks for visiting our docs monastery with the gift of new content! It looks good, but I dropped a few comments so that the resulting document is more coherent, at least according to my humble opinion.
I also feel that even if all my comments are addressed, the document as a whole kind of jumps from general advice to Node.js advice, then to general advice, then to Python advice, then back to Node.js advice, and so on. But I don't know if I'm to poke into that right now. Leaving it up to you, if you feel like the sections could use a better sorting, when you glance over their order.
|
|
||
| See the [Docker image guide](/sdk/js/docs/guides/docker-images) for more details. | ||
|
|
||
| #### Slim images |
There was a problem hiding this comment.
| #### Slim images | |
| ### Node.js slim images |
Oftentimes, flat is better than nested. I wouldn't nest this section as H4, I think it's okay if we use just ### here and a descriptive heading.
There was a problem hiding this comment.
Folded into the intro of Node.js base images instead, so there is no separate heading at all. The two flavours and the recommendation now come before the table.
[🤖] Claude Code using Fable 5
|
|
||
| Every Node.js image is also published as a slim variant, with a `-slim` suffix appended to the tag (e.g. `24-slim`, `24-1.60.0-slim`). Slim images do not preinstall `apify`, `crawlee` or `typescript`. They only ship the browser automation library the image is built around (for example `puppeteer` or `playwright`), and `actor-node:24-slim` ships no npm packages at all. This makes them smaller and faster to pull, and your `package.json` is the single source of truth for dependency versions. | ||
|
|
||
| Use the slim variant unless you have a reason not to. Reach for the full image when you want to run something quickly without maintaining a `package.json`, or when you rely on the exact preinstalled versions of `apify` and `crawlee`. |
There was a problem hiding this comment.
Use the slim variant unless you have a reason not to.
This makes me think that this section should be listed first? So that anyone looking for Node.js images finds this one first and only when they have a reason not to use them, they scroll down to find out more about the base images. Does it make sense? 🤔 And in such case, Reach for the full image could become Reach for the [full image](#anchor-to-the-base-images-section)
There was a problem hiding this comment.
Done. The recommendation is now the first thing under Node.js base images, before the table. Since full and slim are two flavours of every image in the table, I described both in one paragraph rather than a separate section, so no anchor was needed.
[🤖] Claude Code using Fable 5
| 1. Predictability - You know exactly which version you're running | ||
| 1. Debugging - Version-specific issues are easier to track down | ||
|
|
||
| ## Package managers |
There was a problem hiding this comment.
| ## Package managers | |
| ## Node.js package managers |
I don't see this addressing any other managers than those specific to the Node.js ecosystem, so as a reader, I want to know before I start to read this that there isn't anything for me if I use pip or uv.
There was a problem hiding this comment.
Done.
[🤖] Claude Code using Fable 5
|
|
||
| :::note Overriding the linker | ||
|
|
||
| These settings are applied through environment variables (`PNPM_CONFIG_NODE_LINKER`, `YARN_NODE_LINKER`), and both pnpm and yarn give environment variables precedence over `.npmrc` / `.yarnrc.yml`. To use a different linker, override the variable in your `Dockerfile` instead of the config file: |
There was a problem hiding this comment.
This reads in kind of confusing way. I'd streamline the sentences so that the message reads more "from A to B" and not jumping by random:
To use a different linker, use environment variables, such as `PNPM_CONFIG_NODE_LINKER`
or `YARN_NODE_LINKER`. Both pnpm and yarn give environment variables precedence over
`.npmrc` or `.yarnrc.yml`, so you can override the variable in your `Dockerfile` instead
of in the config file:
... code block ...There was a problem hiding this comment.
Reworded, keeping one detail your draft dropped: the images already set the linker via these variables, which is why a config file alone silently does nothing. That is the reason the override has to go into the Dockerfile.
[🤖] Claude Code using Fable 5
|
Regrouping the page by scope is in #2964, stacked on this one, so it can be reviewed separately. [🤖] Claude Code using Fable 5 |
3 participants
Mirrors apify/crawlee#4082 for the Actor Dockerfile page:
-slimtag variants (no preinstalledapify/crawlee/typescript) in the Node.js base images section and the tag naming convention, and recommend them by default.packageManagersupport, flatnode_moduleslinker config,/pkg-cache, and how to override the linker viaENV.:16/:20to:24.[🤖] Claude Code using Fable 5