Snapshot output seems noisy; are we emitting needlessly redundant references?

[varungandhi-src]

If you run scip snapshot on the index generated from running scip-typescript on itself, the output you get for FileIndexer.ts starts with:

  import * as ts from 'typescript'
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/
//            ^^ reference scip-typescript npm typescript 4.6.2 lib/typescript.d.ts/ts/

Are we emitting one reference per use of ts in the file? 😅 This should probably get compressed away, but it'd be nice to avoid doing the work in the first place.

[valerybugakov]

@varungandhi-src, @olafurpg, the issue here comes from the fact that ts doesn't have one definition. The ts variable wraps all the exports from the typescript package into one variable via the namespace import. Definitions for underlying exports are located in multiple files internally, and types are grouped by multiple Typescript namespaces.

The correct way to fix this would be to list links to all namespaces located in the same file but on different lines. Is it possible with the current Symbol structure, or should we only aim to remove duplicates?

[varungandhi-src]

I would expect the following behavior from the index:

• The SCIP index should have multiple definition occurrences, one for each namespace ts block, and a single SymbolInformation for that namespace. It should not be emitting one SymbolInformation for each block (IDK if it is doing that, but if it is, that seems undesirable IMO).
• In the import statement, there should be a single reference occurrence.

Does that make sense? The frontend should already be able to handle multiple definitions for an entity -- there shouldn't be a need to emit multiple references.

[olafurpg]

+1 to @varungandhi-src 's proposal. There should only be one reference occurrence, and multiple definition occurrences (plus a single SymbolInformation).

[valerybugakov]

Had a quick call with @varungandhi-src, will look into the implementation this week 👍