[PhilippeR26]

Motivation and Resolution

Cairo 0 support will be dropped one day. There is no date yet, and it may happen together with a full removal of Cairo 0 from Starknet itself. This PR prepares that day, so that it needs no new analysis.

The calldata codec already keeps Cairo 0 apart: AbiParser0 serializes through requestParser.ts, responseParser.ts and validate.ts, which no other parser uses. The rest of the Cairo 0 code was spread over many files, often inside functions that also serve Cairo 1.

This PR:

• moves the public Cairo 0 units that lived in mixed files to their own files:
  • src/utils/hash/classHash/cairo0.ts: computeHintedClassHash, computeLegacyContractClassHash, nullSkipReplacer;
  • src/utils/transaction/cairo0.ts: transformCallsToMulticallArrays, fromCallsToExecuteCalldata;
• moves Builtins, EntryPointsByType and ContractEntryPointFields from legacy.ts to sierra.ts. CASM uses them, so legacy.ts could not lose its Cairo 0 part without breaking the Sierra types;
• marks every other Cairo 0 specific place with a comment that says what to do on that day. There are two forms:

// Cairo 0 specific: when Cairo 0 support is dropped, remove this test.

// Cairo 0 specific: when Cairo 0 support is dropped, keep this type only if
// Starknet still returns Cairo 0 classes; otherwise remove it.

The first form is for code that only serves Cairo 0. The second is for what depends on whether Starknet still holds Cairo 0 contracts on that day: the detection, the places that choose between Cairo 0 and Cairo 1 (which may then have to refuse a Cairo 0 input with a clear error), LegacyContractClass in the node responses, the existing declare guards and the cairoVersion chain. grep -rn "Cairo 0 specific" src __tests__ lists all 84 markers.

A marker is put where something is declared or decided, not at every use: TypeScript will flag the uses once the declaration changes. Markers are line comments, never inside a JSDoc, so they do not reach the generated API docs.

There is no change of behavior and no change of the public API.

RPC version (if applicable)

Not applicable.

Usage related changes

• None in the library: the public exports and the behavior are unchanged.
• Guide connect_account.md: it said that cairoVersion defaults to '1'. When omitted, it is read from the node.

Development related changes

• New files src/utils/hash/classHash/cairo0.ts and src/utils/transaction/cairo0.ts. pedersen.ts keeps the contract address computation and the Pedersen helpers; its header no longer presents it as the Cairo 0 class hash.
• Builtins, EntryPointsByType and ContractEntryPointFields now live in sierra.ts.
• 84 Cairo 0 specific markers in src/ and __tests__/, test cases included. parsingStrategy.test.ts and requestParser.test.ts also test Cairo 1, so only their Cairo 0 blocks are marked.
• Two comments that called the Cairo 0 code an "island" now carry the marker instead.
• Two outdated comments are fixed: cairoTypeStrategy (it said that nothing reads the strategy yet) and CairoBool (it said that compile refuses 1 for a core::bool, which is no longer true since v11; checked by running it).
• nullSkipReplacer gets an @example.
• Checked: ts:check, ESLint, Prettier, the unit tests and the full suite against devnet pass. The list of names exported by dist (values, namespace members and types: 1647 entries) is identical before and after.

Checklist:

• Performed a self-review of the code
• Rebased to the last commit of the target branch (or merged it into my branch)
• Documented the changes in code (API docs will be generated automatically)
• Updated the tests
• All tests are passing

[github-actions]

🎉 This PR is included in version 11.1.0 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀