Skip to content

feat(hero-13394): new resolutions #67

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.

Sign up for GitHub

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

Merged
hero-daria merged 2 commits into from
Jun 22, 2026
Merged

feat(hero-13394): new resolutions #67

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a1e008b
feat(hero-13394): new resolutions
hero-daria Jun 22, 2026
973285d
feat(hero-13394): new resolutions pt 2
hero-daria Jun 22, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,13 +77,18 @@
"cross-spawn": "7.0.5",
"got": "11.8.5",
"http-cache-semantics": "4.1.1",
"js-yaml": "3.14.2",
"json5": "1.0.2",
"lodash.template": "npm:lodash@^4.17.21",
"markdown-it": "12.3.2",
"lodash.template": "npm:lodash@4.18.1",

@greptile-apps greptile-apps Bot Jun 22, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 lodash.template alias changed from a range to an exact pin

The previous resolution used ^4.17.21, allowing patch and minor updates. The new pin 4.18.1 is exact and will not automatically receive future security patches. This is a minor hardening concern — consider whether this should remain a range like ^4.18.1 so that future lodash patch releases are picked up automatically.

Prompt To Fix With AI 
This is a comment left during a code review.
Path: package.json
Line: 82

Comment:
**`lodash.template` alias changed from a range to an exact pin**

The previous resolution used `^4.17.21`, allowing patch and minor updates. The new pin `4.18.1` is exact and will not automatically receive future security patches. This is a minor hardening concern — consider whether this should remain a range like `^4.18.1` so that future lodash patch releases are picked up automatically.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Fix in Claude Code

"markdown-it": "14.2.0",

@greptile-apps greptile-apps Bot Jun 22, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 markdown-it resolution spans six major versions for markdown-it-terminal

The lock file shows markdown-it-terminal@0.2.1 depends on markdown-it "^8.3.1". This resolution forces it to 14.2.0 — six major versions ahead. Between v8 and v14 the dependency graph changed substantially: entities, mdurl, linkify-it, and uc.micro were all replaced with newer incompatible versions, and punycode.js was added. Any internal API markdown-it-terminal relies on from the v8 surface (e.g. md.core, md.renderer, or plugin registration signatures) that changed in those releases will throw at runtime when the addon renders terminal output.

Prompt To Fix With AI 
This is a comment left during a code review.
Path: package.json
Line: 83

Comment:
**`markdown-it` resolution spans six major versions for `markdown-it-terminal`**

The lock file shows `markdown-it-terminal@0.2.1` depends on `markdown-it "^8.3.1"`. This resolution forces it to `14.2.0` — six major versions ahead. Between v8 and v14 the dependency graph changed substantially: `entities`, `mdurl`, `linkify-it`, and `uc.micro` were all replaced with newer incompatible versions, and `punycode.js` was added. Any internal API `markdown-it-terminal` relies on from the v8 surface (e.g. `md.core`, `md.renderer`, or plugin registration signatures) that changed in those releases will throw at runtime when the addon renders terminal output.

How can I resolve this? If you propose a fix, please make it concise.

Fix in Claude Code

"merge": "^2.1.1",
"micromatch": "4.0.8",
"path-to-regexp": "0.1.12",
"terser": "4.8.1"
"on-headers": "1.1.0",
"path-to-regexp": "0.1.13",
"qs": "6.15.2",
"terser": "4.8.1",
"tmp": "0.2.7",

@greptile-apps greptile-apps Bot Jun 22, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 tmp resolution collapses incompatible major versions

The resolution forces tmp@0.2.7 for all requests including exact pins tmp@0.0.28 and tmp@0.0.33 that appear in the lock file. The tmp 0.2.x line has documented breaking changes: template, name, and dir options must now be relative to tmpdir (absolute paths no longer accepted). Any transitive package that was calling tmp.file({ dir: '/absolute/path' }) or similar will silently produce unexpected results or throw at runtime, because those packages were specifically pinned to 0.0.x and have not been updated for the 0.2.x API contract. The tmp README explicitly calls these out as "Previously Undocumented Breaking Changes" that were only partially reverted.

Prompt To Fix With AI 
This is a comment left during a code review.
Path: package.json
Line: 90

Comment:
**`tmp` resolution collapses incompatible major versions**

The resolution forces `tmp@0.2.7` for all requests including exact pins `tmp@0.0.28` and `tmp@0.0.33` that appear in the lock file. The `tmp` 0.2.x line has documented breaking changes: `template`, `name`, and `dir` options must now be relative to `tmpdir` (absolute paths no longer accepted). Any transitive package that was calling `tmp.file({ dir: '/absolute/path' })` or similar will silently produce unexpected results or throw at runtime, because those packages were specifically pinned to 0.0.x and have not been updated for the 0.2.x API contract. The `tmp` README explicitly calls these out as "Previously Undocumented Breaking Changes" that were only partially reverted.

How can I resolve this? If you propose a fix, please make it concise.

Fix in Claude Code

"uuid": "11.1.1"

@greptile-apps greptile-apps Bot Jun 22, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 uuid resolution jumps three major versions

The lock file resolves a transitive uuid@^8.3.2 dependency, now forced to 11.1.1. While uuid v11 still ships a CommonJS build (the CJS drop happens at v12), there were breaking changes between v8 and v9 (removal of deep-require paths like uuid/v4) and further changes in v10. Any transitive package that uses require('uuid/v4') or similar deep-import patterns will break at runtime. Verifying that no dependency in the tree does this is worth confirming before merging.

Prompt To Fix With AI 
This is a comment left during a code review.
Path: package.json
Line: 91

Comment:
**`uuid` resolution jumps three major versions**

The lock file resolves a transitive `uuid@^8.3.2` dependency, now forced to `11.1.1`. While uuid v11 still ships a CommonJS build (the CJS drop happens at v12), there were breaking changes between v8 and v9 (removal of deep-require paths like `uuid/v4`) and further changes in v10. Any transitive package that uses `require('uuid/v4')` or similar deep-import patterns will break at runtime. Verifying that no dependency in the tree does this is worth confirming before merging.

How can I resolve this? If you propose a fix, please make it concise.

Fix in Claude Code

},
"engines": {
"node": "6.* || 8.* || >= 10.*"
Expand Down
Loading
Loading