In bug 1740290 I'm hoping to massively improve Searchfox's JS indexing support (which is currently very soupy[1]) by changing the indexer to use https://github.com/sourcegraph/scip-typescript which is based on the https://github.com/Microsoft/TypeScript/wiki/Standalone-Server-%28tsserver%29 used by VS Code for JS and TS language server purposes.

For JS/TS files that exist under a jsconfig.json or tsconfig.json tree, indexing is straightforward. But for the rest of the JS codebase, the hardest part of doing this is knowing what type of global a JS file is executing in and any symbols that have already been defined in that global.

Very happily, the amazing work to get eslint working in the tree has already accomplished most of what needs to be done, with eslint-plugin-mozilla providing the heuristics combined with manual annotations so that it seems like globals.js and friends could emit metadata about the files they see. They could emit this as a build artifact that searchfox's follow-on JS indexing[2] can ingest and use to do a bunch of hacks like inject import statements at the top of the JS files that will then have their line numbers be subtracted off or use a (temporarily?) forked version of the scip-typescript indexer that knows how to use the information. This might involve some typescript definition files to help the typescript analysis flow type information as it indexes.

If there's a way that we could help scip-typescript and tsserver understand the global information without extra custom logic/JSON files, that's even better of course[3]. I haven't seen indications of support for this in the jsconfig.json docs or tsconfig.json docs and ref but I'm still learning more about this space.

1: Soupy in the sense that because searchfox has not known about imports before, it effectively assumes that all JS in the tree runs in one big global, including properties/attributes.

2: Right now the searchfox indexing AWS jobs handle things like analyzing JS, but the ideal situation would be that all language analysis happens in mozilla-central taskcluster jobs (like happens for C++ and we're hoping to have happen for XPIDL and IPDL soon). So generating the metadata about JS files would be an improvement. And in general it would be preferable for there to be (potentially new) taskcluster tasks that generate the SCIP analysis data (which can be converted to LSIF). I do expect the SCIP generation phase to involve a bunch of iteration that would be decoupled from mozilla-central at least initially, but once it stabilizes, would be worth considering moving in-tree.

3: While it's great for searchfox to have super-powers and for people to want to use it, I think it's most ideal to support VS Code and other IDEs via the Language Server Protocol, as well as pernosco via LSIF. So pipelines should ideally involve as few searchfox-specific formats/behaviors as possible.