Javascript/Typescript Parser
## Goal
Add support for Javascript and Typescript to the [One Parser project.](https://gitlab.com/groups/gitlab-org/-/epics/17516)
For a (Java|Type)Script file, the parser should yield:
1. Definitions (functions, classes, class methods, and some anonymous functions)
2. References (function/method calls, class instantiations)
3. Imports (ES-module and CommonJS)
It should also compute a fully qualified name (FQN) for each one. These will be used to link nodes together in the [Knowledge Graph Indexer.](https://gitlab.com/gitlab-org/rust/knowledge-graph) For more general information on using imports to resolve FQNs across files, see Jon's epic for the [Python Parser](https://gitlab.com/groups/gitlab-org/-/epics/18004#why-imports).
## Limitations
### Path aliasing via project conf files (like `package.json`)
Node allows users to simplify import statements by allowing path aliasing. This is primarly done using the native [subpath import](https://nodejs.org/api/packages.html#packages_subpath_imports) functionality in `package.json`. It can also be accomplished with using third-party packages like `module-alias`, or with `(js|ts)config.json`, in the case of tsc projects, [Next.js](https://nextjs.org/docs/14/app/building-your-application/configuring/absolute-imports-and-module-aliases), and others. We'd also need to consider alias precendence in some cases, if multiple config files which permit aliasing are used.
```json
{
"imports": {
"#utils/*": "./src/utils/*.js",
}
}
```
This is all the parser would see - the most straightforward approach to resolving this would be read `package.json` separately, and update the import node + FQN while we are parsing this file to resolve the alias.
```javascript
import { myFunc } from '#utils/Helpers';
```
### FQN resolution for anonymous function references
```javascript
const authMiddleware = {
jwt: {
verify: async (token, options = {}) => {
const { secret = process.env.JWT_SECRET, ...jwtOptions } = options;
return promisify(jwt.verify)(token, secret, jwtOptions);
}
}
};
```
While tying anonymous functions to a `variable_declarator` AST node during the FQN mapping step for definitions is tractable e.g `authMiddleware.jwt.verify`, name aliasing of the object or key changes are to difficult to track statically and can pose issues when getting the FQN of references to the anonymous function.
### Built-in object method overloading and assignment
```javascript
// src/file1.js
String.prototype.isValidToken = function (this) {
return this.startsWith('glpat-') || this.startsWith('gldt-');
};
// src/file2.js
String.prototype.isValidToken = function (this) {
return this.startsWith('glpat-');
};
```
Overloading built-in methods globally makes it difficult to resolve the "true" definition of an overloaded function, without doing runtime analysis. In this case, `isValidToken` may point to multiple definitions and any calls to the function might need to be represented with a fuzzy edge, either indicating uncertainty or pointing to a set of all the overloaded byte ranges.
As work on the parser progresses, known limitations of the parser will be listed here.
epic