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

Ouverte Adaptée aux débutants
#37 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Langage dominant
Python
Étoiles
54
Forks
36
Métriques de merge des PR
Aucune PR mergée en 30 j

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.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par package.json dans starter-project et solution, par le package-lock.json commité et par les instructions de l’exercice concernant l’installation des dépendances. Reproduisez le problème avec un npm install vierge dans starter-project, puis exécutez npx tsx src/basicAgent.ts pour confirmer l’échec. La tâche est terminée lorsque les deux configurations de l’exercice utilisent un arbre de dépendances compatible et que le point d’entrée s’exécute sans le package export error.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
javascript
Domaine
build-system
Type d'issue
Bug
Difficulté
2/5
Temps estimé
1-3 heures
Activité
Active
Clarté
Clairement spécifiée
Accessibilité débutants
76/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.