fix: wire local packages via npm workspaces instead of manual npm link

[Copilot]

shared was missing from the root workspaces array, and neither client nor server declared game-engine / chess-shared as dependencies. The workaround was a fragile postinstall hook that manually built game-engine and used global npm link symlinks.

Changes

• package.json — add "shared" to workspaces; drop postinstall hook
• client/package.json, server/package.json — declare "game-engine": "*" and "chess-shared": "*" as explicit dependencies
• shared/package.json — declare "game-engine": "*" (its api/types.ts uses import type from it)
• scripts/link-packages.sh — replaced with a no-op; workspaces handle symlinking automatically
• README.md — remove the now-obsolete postinstall entry

After these changes npm install at the repo root is sufficient. npm workspaces resolves both packages to their local TypeScript source:

node_modules/game-engine  →  ../game-engine
node_modules/chess-shared →  ../shared

Original prompt

does this work as expected? does it know to use local packages?

[Chronological Review: The conversation began with the user asking if the current setup works as expected and if it knows to use local packages. The user then canceled the previous request and delegated to a cloud agent. The user repeated the question about the functionality of the setup, indicating a focus on local package usage. The context was established with the current date and the user's active file being the package.json located in the chess client directory.]

[Intent Mapping: The user explicitly requested confirmation on whether the setup works as expected and if it recognizes local packages. This indicates a concern about the configuration of dependencies in the project.]

[Technical Inventory: The conversation involves the following technologies and configurations:

• Node.js: Implicitly referenced through the package.json file.
• React: The project uses React and related libraries.
• Vite: A build tool mentioned in the scripts section of package.json.
• Local Packages: The user is inquiring about the recognition of local packages like "chess-shared" and "game-engine".]

[Code Archaeology: The active file discussed is:

• File Name: package.json
• Purpose: This file manages project dependencies and scripts for the client application.
• Current State: The user is focused on lines 7 to 9, which include dependencies for "chess-shared" and "game-engine".
• Key Code Segments: The dependencies section indicates the use of local packages with wildcard versions.
• Dependencies: The local packages are expected to be recognized by the project setup.]

[Progress Assessment: The user has not yet received a definitive answer regarding the functionality of the local package recognition. The inquiry remains open.]

[Context Validation: The user is seeking clarity on the functionality of their project setup, specifically regarding local package usage, which is critical for their development process.]

[Recent Commands Analysis:

• Last Agent Commands: The user requested confirmation on whether the setup works as expected and if it recognizes local packages.
• Tool Results Summary: No specific tool results were returned as the conversation was primarily focused on user inquiries.
• Pre-Summary State: The agent was actively addressing the user's questions about the package.json configuration and local package recognition when the token budget was exceeded.
• Operation Context: The commands were executed to clarify the functionality of the project setup, which is essential for the user's development goals.]

1. Conversation Overview: - Primary Objectives: The user requested, "does this work as expected? does it know to use local packages?" indicating a need for confirmation on the functionality of their project setup. - Session Context: The conversation has revolved around the user's concerns about the recognition of local packages in their project configuration, specifically within the package.json file. - User Intent Evolution: The user reiterated their question about local package functionality, suggesting a strong focus on ensuring their dependencies are correctly configured.

2. Technical Foundation:

• Node.js: Used for managing project dependencies.
• React: Framework for building the user interface.
• Vite: Build tool referenced in the package.json scripts.
• Local Packages: The user is inquiring about the recognition of local packages like "chess-shared" and "game-engine".

3. Codebase Status:

• File Name: package.json
• Purpose: Manages project dependencies and scripts for the client application.
• Current State: The user is focused on the dependencies section, particularly lines 7 to 9.
• Key Code Segments: Dependencies include "chess-shared" and "game-engine" with wildcard versions.
• Dependencies: Local packages are expected to be recognized by the project setup.

4. Problem Resolution:

• Issues Encountered: Uncertainty about whether local packages are recognized in the current setup.
• Solutions Implemented: None yet, as the user is seeking confirmation.
• Debugging Context: Ongoing inquiry into the functionality of the package configuration.
• Lessons Learned: The importance of confirming local package recognition for project functionality.

5. Progress Tracking:

• Completed Tasks: No tasks have been completed regarding the confirmation of local package functionality.
• Partially Complete Work: The inquiry about local package recognition is still open.
• Validated Outcomes: No features or code have been confirmed working through testing yet.

6. Active Work State:

• Current Focus: The user is focused on understanding the functionality of their package.json configuration.
• Recent Context: The user has asked multiple times about the recognition of local packages.
• Working Code: The relevant code being discussed is from the package.json file.
• Immediate Context: ...

Created from VS Code.

[mterczynski]

@copilot answer the question, do not output anything else

HOW does chess-shared * work - how does npm know to link it to our chess-shared, not to any remote chess-shared

[Copilot]

@copilot answer the question, do not output anything else

HOW does chess-shared * work - how does npm know to link it to our chess-shared, not to any remote chess-shared

npm resolves "chess-shared": "*" to the local workspace package — not any remote registry — because the root package.json lists "shared" in its "workspaces" array and that workspace's package.json declares "name": "chess-shared".

When npm sees a dependency whose name matches a workspace package name, it always prefers the local workspace over the registry, regardless of the version specifier. The * just means "any version", but the match against the workspace name takes priority first. This is documented npm workspaces behaviour.

[mterczynski]

@copilot i dont see your reply to my last prompt

[Copilot]

@copilot i dont see your reply to my last prompt

My reply is directly above this comment in the thread. To summarise: npm always prefers a local workspace package over the registry when the dependency name matches a workspace's "name" field. Because shared/package.json declares "name": "chess-shared" and "shared" is listed in the root "workspaces" array, npm resolves "chess-shared": "*" to ./shared — never to any remote package.