General

Git & Version control

• Do not use release in your branch name if it is not a release,
  • Use lowercase & DNS-friendly only, multistaging is unhappy otherwise
  • You can start with fix, feat, chore
• PR title + PR descriptions
  • See README.md in apify core - Submitting code changes
  • Write a description - what is changed by your code, why you did the change like this etc.
    • You can add comments from you (author) if things get complicated

Code review process

• You should always have 2 approvals from engineers on common PRs.
  • It’s beneficial to combine someone aware of an initiative with someone experienced in that part of the codebase.
  • When fixing a release, try to have at least 1 approval.
• When you are working on the frontend (client-side, not admin), request a review from design and wait for approval.
• When changing strings, the content team should be assigned automatically. If the change is user-facing, wait for their approval as well.

AI tools

Request the AI tools you want to use via #apify-request-access, and we support them (Claude Code, GitHub Copilot, JetBrains AI, and Cursor).

Common code rules

This section contains rules that are applicable to all repositories (TS and Python).

Avoid else, return early

• Return as soon as you know your method cannot do any more meaningful work

• Reduce indentation by using if/return instead of a top-level if/else

• Try to keep the “meat” of your method at the lowest indentation level.

• For more, see:

  https://github.com/zakirullin/cognitive-load

TypeScript