JS-1453 Add TS ecosystem telemetry for project analysis#6615
JS-1453 Add TS ecosystem telemetry for project analysis#6615
Conversation
Ruling Report✅ No changes to ruling expected issues in this PR |
zglicz
left a comment
zglicz
left a comment
There was a problem hiding this comment.
I would also like to have some js tests and verify that the telemetry object gets populated properly. We have multiple good folders with fixtures setup and different tsconfigs, package.jsons. We want to have good coverage on this data aquisition.
packages/jsts/src/analysis/projectAnalysis/analyzeWithProgram.ts
Outdated
Show resolved
Hide resolved
zglicz
left a comment
zglicz
left a comment
There was a problem hiding this comment.
All of this serialization of the compiler options is very verbose and should be using some built in/npm package. Also, fix the sonarqube issues
| const tsProgram = createStandardProgram(programOptions, { | ||
| onProgramCreated: () => telemetry.recordProgramCreationSuccess(), | ||
| onProgramCreationError: () => telemetry.recordProgramCreationFailure(), | ||
| }); |
There was a problem hiding this comment.
why pass the callbacks? They could be simply invoked in the createStandardProgram. I dont think we need to customize this functionality
zglicz
force-pushed
the
codex/js-1453-language-version-telemetry
branch
from
019c4c7 to
bc5cd72
Compare
SummaryThis PR adds project-level TypeScript ecosystem telemetry collection to the JS/TS analyzer. During project analysis, it tracks: TypeScript versions detected in package.json, native preview usage, compiler options union across all programs, ECMAScript versions used, and TS program creation counters (attempted/succeeded/failed). The telemetry is collected on the JS/TS side, transmitted through the bridge to the plugin, and reported under What reviewers should knowStart by reviewing the new telemetry.ts file to understand the collector design and normalization logic (especially how enum values and lib paths are converted to strings). Then trace how it flows: analyzeProject.ts resets and retrieves telemetry, analyzeWithProgram.ts passes the collector through analysis functions to record options/versions, createStandardProgram.ts wraps program creation to track success/failure. On the bridge side, note the new DTOs in BridgeServer.java. Finally, check PluginTelemetry.java to see how it formats the data for SonarQube. Key gotcha: telemetry uses global state that's reset per analysis—verify the initialization/cleanup pattern in tests. The normalization of compiler option values (especially for enum types and lib values) preserves readability while handling TypeScript's internal representations.
|
zglicz
force-pushed
the
codex/js-1453-language-version-telemetry
branch
from
fd30a63 to
27df753
Compare
| function getAvailablePackageJsons(): PackageJson[] { | ||
| const packageJsons: PackageJson[] = []; | ||
| for (const packageJsonFile of getPackageJsonFiles()) { | ||
| const packageJson = parsePackageJsonFile(packageJsonFile.content); | ||
| if (packageJson !== undefined) { | ||
| packageJsons.push(packageJson); | ||
| } | ||
| } | ||
| return packageJsons; | ||
| } | ||
|
|
||
| function getPackageJsonFiles(): Iterable<{ content: string | Buffer }> { | ||
| try { | ||
| return packageJsonStore.getPackageJsons().values(); | ||
| } catch { | ||
| return []; | ||
| } | ||
| } | ||
|
|
||
| function parsePackageJsonFile(content: string | Buffer): PackageJson | undefined { | ||
| const packageJsonContent = typeof content === 'string' ? content : content.toString(); | ||
| try { | ||
| return JSON.parse(stripBOM(packageJsonContent)) as PackageJson; | ||
| } catch { | ||
| return undefined; | ||
| } | ||
| } |
There was a problem hiding this comment.
I think this logic should go into the dependencies module handling packageJsons, if we want to keep the parsed contents I would rather keep them there
| function getTypeScriptOptionDeclarations(): TypeScriptOptionDeclaration[] { | ||
| return ((ts as unknown as { optionDeclarations?: unknown[] }).optionDeclarations ?? | ||
| []) as TypeScriptOptionDeclaration[]; | ||
| } |
There was a problem hiding this comment.
better use CompilerOptions which is public
…6630) Co-authored-by: Victor <victor.diez@sonarsource.com>
![sonar-review-alpha[bot]](https://avatars.githubusercontent.com/in/3025063?s=60&v=4){kind=small}
There was a problem hiding this comment.
The previous logic duplication comment (ID 2947469058) has not been addressed. The refactor in this commit introduced getDependencyVersionSignal and isValidDependencySignal helpers, and partially applied them — but getNodeVersionSignal still uses an inline guard (typeof typesNode === 'string' && typesNode !== 'latest' && typesNode !== '*') instead of calling isValidDependencySignal(typesNode). The duplication remains.
This reverts commit d3d657a.
|
2 participants
Summary
metawebsocket payload and extend bridge DTOs to carry itjavascript.telemetry.*while keeping existingjavascript.runtime.*keys unchangedValidation