Add an editor/language-service API to cel-js

[AntonPieper]

Editor integrations currently need to reimplement a lot of CEL intelligence outside cel-js.

I would like a first-class API on a LanguageService, for example:

import { createLanguageService } from "@marcbachmann/cel-js/language-service";

// If tree-shaking is no concern:
// const ls = env.languageService();
const ls = createLanguageService(env);

ls.complete(source, cursor, options?);
ls.hover(source, cursor, options?);
ls.diagnostics(source, options?);
ls.signatureHelp(source, cursor, options?);
ls.symbols(source, cursor, options?);

Lower-level primitives in Environment would also help, for example:

• env.resolveAt(source, cursor)
• env.scopeAt(...)
• env.membersOfType(...)

The main goal is to avoid sentinel hacks, manual scope reconstruction, manual receiver inference, and custom hover/completion logic in editor consumers.

[marcbachmann]

hmm, Is there no golang based language service? 🤔 🙃

[AntonPieper]

I couldn't find a ready-made Go-based LS that I can directly plug in here, and cel-go itself still seems to be discussing that area rather than shipping a first-class one.

I also tried this from the third-party side, and I think I asked for too much at once. A full built-in LS probably isn't necessary.

The minimal low-level pieces that seem needed are just:

env.getRegistry()
env.parse(source, { recover?: boolean, cursor?: number })
env.checkAst(ast, { collectBindings?: boolean })

That would already let an external LS do accurate and efficient completions/hover/signature help with docs for functions/constants/macros.

The important bit is collectBindings: built-in macros are mostly fine via expansion + checking, but arbitrary custom macros can introduce scope/bindings in checker logic, and that part can't be reconstructed generically outside cel-js.

[marcbachmann]

Thanks. In any case, some implementation/exploration needs to drive that idea.
In case you do an implementation in a separate repo/module? What is exactly needed to support this?

Maybe just start in a PR an explore a bit? I don't want to bloat the main module size too much (client/browser side compatibility must be guaranteed), so needed in the main evaluation path must be minimal.