build: Node and pnpm versions are not pinned for the monorepo

[mssystem1]

Summary

The get-starknet repository requires contributors to use Node and pnpm, but does not currently define a supported Node version or pin the pnpm version used by the repository.

The README only states:

You need Node and pnpm installed.

and instructs users to run:

pnpm install
pnpm build

The root package.json does not define:

"packageManager": "pnpm@..."

or:

"engines": {
  "node": "...",
  "pnpm": "..."
}

This makes local development and dependency resolution dependent on whichever Node/pnpm versions happen to be installed on the contributor's machine.

Affected Files

Repository:

starknet-io/get-starknet

Files:

package.json
README.md
pnpm-lock.yaml

Current Behavior

The root package uses pnpm-specific commands extensively:

{
  "scripts": {
    "build": "pnpm run -r build",
    "dev": "pnpm run -r --parallel dev",
    "prepare": "pnpm run build && husky install",
    "publish": "pnpm publish -r --no-git-checks --access public && changeset tag",
    "publish:next": "pnpm publish -r --no-git-checks --access public --tag next && changeset tag",
    "test": "CI=true pnpm run -r test",
    "version": "changeset version && pnpm install --lockfile-only"
  }
}

However, there is no pnpm version pin.

The repository also contains:

pnpm-lock.yaml
pnpm-workspace.yaml

which means package-manager behavior is part of the reproducible build environment.

Problem

Different pnpm major versions can behave differently with respect to:

• lockfile format;
• peer dependency resolution;
• workspace linking;
• lifecycle scripts;
• optional dependencies;
• lockfile updates.

The repository already sets:

strict-peer-dependencies=false

in .npmrc, making package-manager behavior relevant to dependency resolution.

A contributor using a different pnpm version can therefore modify the lockfile or install a dependency graph that differs from CI/release tooling.

Expected Behavior

The repository should define the package-manager version expected for development and release work.

For example:

{
  "packageManager": "pnpm@10.15.0",
  "engines": {
    "node": ">=22"
  }
}

The exact versions should of course match the versions used by CI.

Suggested Fix

Add a packageManager field:

{
  "packageManager": "pnpm@<ci-version>"
}

and preferably an explicit Node version policy:

{
  "engines": {
    "node": ">=<supported-version>"
  }
}

Then update the README:

### Development requirements

- Node.js: `<supported version>`
- pnpm: `<pinned version>`

With Corepack:

```bash
corepack enable
pnpm install --frozen-lockfile

## Optional CI Improvement

CI should verify that the lockfile is unchanged after installation:

```bash
pnpm install --frozen-lockfile
git diff --exit-code pnpm-lock.yaml

This prevents accidental package-manager drift from being merged.

Why This Matters

This repository publishes wallet-connection packages consumed by Starknet dApps.

Reproducibility is especially useful for:

• releases;
• dependency audits;
• debugging;
• package provenance;
• contributor onboarding;
• lockfile stability.

Impact

Severity: Low

Category:

• build reproducibility
• developer experience
• dependency management

Potential consequences:

• unexpected lockfile diffs;
• dependency-resolution differences;
• CI/local inconsistencies;
• release behavior depending on local pnpm version;
• harder-to-reproduce package builds.

Environment

Repository:

starknet-io/get-starknet

Branch:

master

Package manager:

pnpm

Workspace:

pnpm-workspace.yaml