Code Monkey home page Code Monkey logo

Comments (2)

morgante avatar morgante commented on June 12, 2024 1

We definitely want to release a Node SDK at some point, though I'm undecided on which of a few approaches to take:

  1. Make the SDK a wrapper around calling the grit binary (as a subprocess). There's nothing fundamentally wrong with this except a large binary size, and avoids needing to optimize another API surface.
  2. Use napi to create a native Node addon. This has the advantage of native interfacing, but I don't know how well it will work with the (extensive) multithreading we do for performance.
  3. Use our wasm bindings from node. These already exist and avoid needing to distribute native addons for each platform, but I don't think we can do multi-threading.

The other thing to decide would be which API to surface.

from gritql.

transitive-bullshit avatar transitive-bullshit commented on June 12, 2024

For now, I ended up going with option 1.

You can see my PoC here with more info on the PR and motivations here. Note that this project is not OSS yet, but it will be hopefully by end of week, so I'm just documenting my exploration as I go for anyone else who's interested in this type of integration.

So far, using grit as a subprocess with @getgrit/launcher as an optional dependency seems like a good solution to maximize compatibility, with the linting engine still working even if grit fails to install on some platforms. I'm currently only using grit apply --dry-run --jsonl with a readonly pattern, and this is only enabled for any markdown rules which contain an optional grit or gritql code block like this one: https://github.com/gptlint/gptlint/blob/feature/gritql/.gptlint/prefer-array-at-negative-indexing.md.

I've done an initial analysis on using gritql to filter the source file context sent to our LLM-based linting engine, and it reduces the context significantly for several of the built-in rules, which is amazing. I still need to do a full suite of evals w/ gritql ablations to see how this impacts rule accuracy / precision / recall / cost / speed at scale, but I'm really happy with the results so far. A lot of files which we were previously naively linting can be quickly ruled out without doing any LLM calls if there are no gritql matches.

btw if anyone else is exploring similar integrations and wants to chat, feel free to DM me. Cheers 👋

from gritql.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.