SAP-samples / SAP-samples/codejam-code-based-agents

JavaScript track: npm install can resolve an incompatible @langchain/core, even though the committed lockfile is fine

Open Beginner friendly
#37 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
54
Forks
36
PR merge metrics
No merged PRs in 30d

Description

Summary

package.json (both starter-project and solution) pins:
json "@langchain/core": "1.1.39", "@langchain/langgraph": "1.2.8", ​

The committed package-lock.json resolves @langchain/langgraph-checkpoint (a transitive dependency of @langchain/langgraph) to 1.0.1, which is compatible with @langchain/core@1.1.39. So the lockfile itself is internally consistent.

The problem: the exercises instruct learners to run npm install, not npm ci. npm install can re-resolve transitive dependencies against whatever's currently newest on the npm registry rather than strictly honoring the lockfile. @langchain/langgraph-checkpoint has since published newer versions (currently 1.1.3) that require @langchain/core: ^1.1.48 — incompatible with the exact 1.1.39 pin. A fresh npm install today resolves to this newer, incompatible version.

Effect

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './utils/uuid' is not defined by "exports" in .../node_modules/@langchain/core/package.json imported from .../@langchain/langgraph/node_modules/@langchain/langgraph-checkpoint/dist/id.js ​
thrown immediately on npx tsx src/basicAgent.ts (or any entry point importing @langchain/langgraph), since @langchain/core@1.1.39 doesn't yet expose the ./utils/uuid export subpath that the newer langgraph-checkpoint@1.1.3 needs.

Suggested fix

Either:

  1. Bump the pinned @langchain/core version in package.json to something satisfying ^1.1.48 (e.g. 1.1.49 or later), removing the fragility of the exact pin against a moving transitive dependency, or
  2. Have learners run npm ci instead of npm install in the exercise instructions, so the exact working dependency tree from the committed lockfile is used rather than a fresh, potentially-drifted resolution (tradeoff: learners then don't get any newer patch versions of pinned packages).

Option 1 is more robust long-term, since this kind of drift will keep recurring as the npm ecosystem publishes new versions over time, regardless of the lockfile.

Environment

Reproduced on a personal SAP AI Core tenant, JavaScript/TypeScript track, npm install run fresh in starter-project/ (not npm ci), Node.js v24.18.0.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with package.json in both starter-project and solution, the committed package-lock.json, and the exercise instructions for dependency installation. Reproduce with a fresh npm install in starter-project, then run npx tsx src/basicAgent.ts to confirm the failure. Done means both exercise setups use a compatible dependency tree and the entry point runs without the package export error.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
build-system
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
76/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.