Skip to content

Expose and document the parser AST + toJS() in the published types #2498

Description

@assapir

What we use

Three things from AlaSQL internals:

const ast = alasql.parse('SELECT 1 FROM ? WHERE x < $y');
const where = ast.statements[0].where;        // ← undocumented
const js = where.toJS('p', '', null);         // ← undocumented; emits a JS expression string
const fn = new Function('alasql', 'p', `return Boolean(${js});`);

We also rely on stable AST node shapes — Op{left, op, right}, Column{columnid, tableid}, ParamValue{param}, NumValue{value}, StringValue{value}, LogicValue{value}, UniOp{op, right} — to walk the tree.

What's in the published types today

interface AlaSQLAST {
  compile(databaseid: string): AlaSQLStatement;
}

That's it — nothing about statements[], where, toJS(), or AST node shapes. Even though they've been stable for years.

The ask

Type-only. Add statements: Statement[] to AlaSQLAST and document the node shapes + the Expression.toJS(context, tableid, defcols) signature in alasql.d.ts, with a note that these shapes follow semver.

Nothing new gets built — just publishing types for what's already there.

Why

Downstream consumers using AlaSQL as a parser/codegen (rather than a full query engine) currently do as unknown as {statements: ...} casts through the type system. A documented surface puts these consumers on a stable footing.

Happy to submit the PR if there's interest.

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions