TypeScript support

[alex-dixon]

Ell TypeScript

Goals

1. Feature parity with Python
2. Unobtrusive/frictionless DX

Challenges

1. Capturing TypeScript source code - Ell captures user source code as written, the same as it looks in the user’s IDE. TypeScript is compiled to JavaScript before. Mostly this means type annotations are stripped. We need to read the code before this happens (before runtime and at or before compile time) or have a way to get to the source from runtime code/JavaScript (source maps).
2. Lexically closed-over definitions and values - Ell captures the source code of all variables in scope of the decorated function and records their values at runtime. These include module-level locals that are referenced in the decorated function. We’re open to ideas on how to do this in TypeScript unobtrusively. One idea could be to use Node’s inspector/debugger API.

Implementation requirements

• ell needs LMP version id when it writes an invocation trace
• LMP version requires the program's source code (to create a hash that serves as a version/id)
• The source code is only guaranteed to be available at compile time (not necessarily at runtime)

Given this we need to get the source code at compile time.

HOWEVER:

• users may combine their compile and run steps if they use ts-node, bun, or (in the near future) NodeJS. This guarantees the source is available at runtime, and likely to ell.

Compile only

DX

Instead of:

tsc 

Users run:

ell tsc

Or

ell tsc —watch

This compiles TS and all LMPs using a TypeScript compiler plugin.

A source file is created and imported at runtime by ell typescript that contains LMP names by file path relative to the compilation root. Note: Matching this key at runtime is sound only if we match on greatest common substring of the __filename / path to file.

Requirements

• __filename / import.meta points to a JS file of the same name as the source file
• Directory structure between compilation and runtime is preserved
• Ability to write out our own file and access it at runtime

Compile+run

DX

ts-node calculator-example.ts

• Works just like ell python
• Creates LMPs at runtime on a per-use basis

Requirements

• Users must run their code with ts-node or similar
• __filename for CommonJS modules or import.meta.url for ES Modules is available and references the original source file
• Read access to the original source file
• A TS server running in forked process or TypeScript compiler running in the same process
• In-memory cache of LMPs per file and their source text

React with 👍 to help us prioritize this issue!

[alex-dixon]

cc @MadcowD @emfastic

[emfastic]

@alex-dixon thanks for writing this up! To pick one version to implement first, I think we should go with the compile and run. I played around with compile time a few weeks ago and was dissatisfied.

It seems things are trending towards just running Typescript files and makes more sense for us to build in that direction.

What's your preference? Any problems you see with focusing on this first?

cc @MadcowD

[alex-dixon]

@emfastic Sounds good to me.

The AST code can be used for both and we have a start on it in the PR.

I have a plan for the ell tsc implementation that I’ll document in the PR.

[tonyabracadabra]

this is awesome! let me know if I can help!

[shivaylamba]

Is someone developing this? @alex-dixon

[alex-dixon]

@shivaylamba yes! Pr going here #162

[alex-dixon]

We’re getting close to a release.

Check out the PR for a sneak peak:

git clone https://github.com/alex-dixon/ell.git
git checkout typescript
cd typescript 
npm i

Run an example:

export OPENAI_API_KEY=sk-abc
ts-node -T examples/hello_world.ts