Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[tsp-client] Change dependency pinning logic in generate-config-files command #9817

Open
catalinaperalta opened this issue Feb 11, 2025 · 2 comments
Assignees
Labels
TypeSpec Issues or feature requests for tooling to support TypeSpec (Cadl)

Comments

@catalinaperalta
Copy link
Member

catalinaperalta commented Feb 11, 2025

Change the pinning algorithm in generate-config-files so that instead of using the emitter's pinned devDependencies in their package.json, search for the latest pinned dependency in the emitter's package-lock.json file.

[WIP] 
cc @hallipr

@catalinaperalta catalinaperalta added the TypeSpec Issues or feature requests for tooling to support TypeSpec (Cadl) label Feb 11, 2025
@catalinaperalta catalinaperalta self-assigned this Feb 11, 2025
@hallipr
Copy link
Member

hallipr commented Feb 18, 2025

General NPM

  1. CI runs should use npm ci instead of npm install for safety and consistency:
    https://docs.npmjs.com/cli/v11/commands/npm-ci
  2. npm ci requires a lock file and when creating package-lock.json using npm install, the only way to force a floating peer dependency range to resolve to an expected version is to declare that specific version as a dependency (pinning)
  3. pinning the version using dependencies would break consumers that depend on multiple emitters that pinned different versions
  4. pinning using devDependencies allows us to control the version that ends up in package-lock.json without forcing all consumers to us the same pinned version.

Azure SDK Specifics

  1. emitter-package.json needs emitter-package-lock.json for the same "safety in ci" reason above.
  2. like any other package.json -> package-lock.json, the best way for us to control the resolved version for all of our floating peer dependency ranges is to use devDependencies.
  3. tsp-client generate-config-files can ensure that emitter-package.json and the emitter share the same devDepedency pins as long as there's hinting to tell it which packages need to be pinned and what version to pin them to.

Proposed algorithm:

  1. Scan package-lock.json for all peer ranges in the emitter package and its dependencies recursively
  2. Use either package-lock.json or npm list --all --json to gather the resolved version for all floating peer ranges
  3. Use the resolved versions for devDependency pinning in emitter-package.json so that emitter-package-lock.json generation becomes more deterministic.

@hallipr
Copy link
Member

hallipr commented Feb 18, 2025

@mikeharder, what do you think about using the package-lock.json from the emitter as a source for peer dependency pinning in emitter-package.json?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TypeSpec Issues or feature requests for tooling to support TypeSpec (Cadl)
Projects
None yet
Development

No branches or pull requests

2 participants