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

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions