fix: declare dedent as an explicit dependency in @herb-tools/linter

[jleo3]

Fixes #2213.

dedent is imported in src/rules/erb-no-conditional-html-element.ts and src/cli/argument-parser.ts but was missing from dependencies in javascript/packages/linter/package.json. This causes ERR_MODULE_NOT_FOUND for anyone importing the unbundled dist/ modules directly.

Change

Add "dedent": "^1.7.2" to dependencies (version already present in yarn.lock).

Why it was invisible

bin/herb-lint loads the pre-bundled dist/herb-lint.js which already inlines dedent, so the CLI path is unaffected. The missing declaration only surfaces when importing dist/rules.js or individual rule modules directly.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[luantaraschi]

The diagnosis checks out. On main, javascript/packages/linter/package.json lists @herb-tools/*, @ruby/prism, picomatch and tinyglobby, and dedent appears in neither dependencies nor devDependencies, while src/cli/argument-parser.ts:1 and src/rules/erb-no-conditional-html-element.ts:1 both do import dedent from "dedent". The ^1.7.2 you picked also matches what language-server already declares, so the version is consistent with the rest of the repo.

One thing worth knowing before this merges, since it changes how you might want to scope it: the linter is not the only package with this shape. Sweeping every package for a real import dedent from "dedent" under src/ and comparing against its manifest:

package	import dedent in src/	declares dedent
linter	2 files	no, this PR
formatter	3 files	no
highlighter	1 file	no
language-service	2 files	no
printer	2 files	no
vscode	1 file	no
language-server	none	yes, ^1.7.2

So six packages import it undeclared, and the one package that declares it does not import it anywhere in src/. Every one of them would hit the same ERR_MODULE_NOT_FOUND on a direct dist/ import, for the same reason: the bundled entry points inline it and hide the gap.

That is not a reason to hold this PR. Fixing the package the issue was filed against is a fine unit of work, and the version choice is already right. It might be worth a follow-up that declares it in the other five and drops it from language-server, or, if you would rather have one sweep than seven, this PR could grow into it. Happy to send the follow-up myself if you prefer to keep this one as is.

Small note on what I could and could not run: this repo does not check out on Windows, because three fixtures under config/action_view_helpers/ have ? in their filenames, which NTFS rejects. So I read everything through git show and git grep against the object store rather than a working tree, and I did not run the test suite or reproduce the import failure end to end. The manifest and the imports are plain facts of the tree, so I am confident in those; the runtime claim I am taking from your description, which reads correctly against the bundling setup.

[luantaraschi]

Correcting my own table above, since I built the follow-up on it and two rows were wrong.

I had grepped for dedent too loosely. language-service does not import the package at all: it has its own local dedent helpers, a private method in extract_partial_analyzer.ts and a function in hover_provider.ts, and only uses the package in tests. And formatter does import it in src/, but its build inlines it, so it has nothing to declare either. I checked that against the published 0.10.3 tarballs rather than the source this time:

package	import dedent in src/	external import in the published dist/
linter	2 files	2 files, this PR
printer	1	dist/cli.js:2
highlighter	1	dist/cli.js:1
formatter	2	none, inlined
vscode	1	private package, esbuild-bundled
language-service	none	none

So it is two packages beyond this one, not five. I opened #2231 for those, and it leaves the linter to you here.

The part that did hold up is the failure itself: npm install @herb-tools/printer@0.10.3 in an empty project and running its CLI gives ERR_MODULE_NOT_FOUND: Cannot find package 'dedent', exactly the shape you described. Sorry for the noisy first count.

[jleo3]

Thanks for doing the extra research @luantaraschi. Happy to keep the PRs separate and hopes this helps someone else.