feat(razor): index inline <script> JS in .cshtml/.razor views#959
Open
Johnny-Tsai wants to merge 1 commit into
Open
feat(razor): index inline <script> JS in .cshtml/.razor views#959Johnny-Tsai wants to merge 1 commit into
Johnny-Tsai wants to merge 1 commit into
Conversation
Traditional ASP.NET MVC / Razor views put front-end logic in inline <script> blocks that import and call shared JS modules. These were previously invisible to the graph, so a JS helper never showed its calling views as dependents. This extracts JS (and TS via lang="ts") inside <script> blocks of a Razor component and attributes the unresolved references to the component node, lightweight-style (no extra per-function nodes, so the node count stays stable). The key detail is tagging these refs in the `javascript`/`typescript` language family rather than `razor` — otherwise the dotnet-family language gate drops cross-family JS references. Directive refs (@model, Blazor tags, @code) keep their existing razor (dotnet) tagging; only <script> contents get the web-family tag. Verified with a synthetic test plus a large real-world .NET ERP repo where view callers of shared JS helpers now surface correctly. Part of colbymchenry#648, closes colbymchenry#319. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Index JavaScript (and TypeScript via
lang="ts") inside<script>blocks of Razor /.cshtmlviews, so that a shared JS module/function correctly shows its calling views as dependents.Closes #319 (part of #648).
Why
Traditional ASP.NET MVC / Razor views routinely put front-end logic in inline
<script>blocks thatimportand call shared JS helpers. Before this change those<script>contents were invisible to the graph — a JS helper never listed the views that call it, soimpact/ blast-radius missed real front-end callers.How
<script>block extraction torazor-extractor.ts: each block's JS/TS is run through the existingTreeSitterExtractor, and its unresolved references are attributed to the component node (lightweight style — no extra per-function nodes, so node count stays stable, consistent with the design doc invariant).javascript/typescriptlanguage family, notrazor. The dotnet-family language gate would otherwise drop cross-family JS references. Directive refs (@model, Blazor tags,@code) keep their existing razor (dotnet) tagging — only<script>contents get the web-family tag.<script>blocks with a non-JStype(e.g.text/htmltemplates) are skipped.Testing
extraction.test.ts(Razor / Blazor markup extractiondescribe): an inline<script>that imports + calls a shared helper makes the.cshtmlview appear in the helper's impact radius. All existing Razor tests still pass.🤖 Generated with Claude Code