Skip to content

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

@assapir

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
    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