Show HN: Openleetcode – Local LeetCode runner where tests live in the repo
github.comYou write a standard solution, just like on LeetCode, and run it through the CLI. It identifies the problem by ID or title, executes your code against local test cases, and shows the result.
It currently supports around 1.4k problems and multiple languages, including Python, C++, Rust, Java, Go, TypeScript, Swift, and others.
The project is still an MVP. System design, SQL, and concurrency problems are not supported yet, but support for more problem types is planned.
Made in Haskell!
I just prompt my ai coding assistant directly to scaffold out problems and test cases.
One nice thing is the LLM can “reason” about my weak areas and tailor the drills it generates next to keep me on a productive path.
I personally don’t get much value from pulling in 1,400 arbitrary problems but this is cool for people who want to hit the ground running.
- do you mind explaining why you picked this backend? https://github.com/engineer-man/piston
- you could simply spawn a docker container for each programming language and run user submitted code inside no?
Why is leet code even a thing past 2024
Because it's fun!
because coding is a skill and by outsourcing it to AI you lose that skill
This is such a cool idea, I can't believe it hasn't been done before!
> It currently supports around 1.4k problems and multiple languages, including Python, C++, Rust, Java, Go, TypeScript, Swift, and others.
It would be interesting to have a variant where you get the input data through stdin or a file on disk, and verify by writing to stdout. That way you could bring your own language
Nice! The idea of having a friday leetcode problem for my team has been kicked around to try and keep us on our toes when it comes to solving these style problems and preventing atrophy of this part of our brain. Might try wrapping this cli in some kind of web ui or adding it to our slackbot
What a great idea for a project. Will try out. Any thoughts on supporting a CLI (or TUI) interface for browsing through the problem sets locally (titles, descriptions, difficulty, etc.)? On that note, open to contributions? And much respect for choosing Haskell.
In our tests we don't store any metadata other than the ID and the title, and to be honest, I think that's beyond the scope of this project.
Very cool. What motivated you to build this and what use case do you see for this project ?
I love open source and open systems in general. Popular competitive programming platforms aren't like that: not only is their source code closed, but they also don't publish the test cases used to evaluate submissions.
There are already projects that can submit your solutions through the LeetCode API and return the results. But I don't really like that approach, so I decided to build an open set of tests that aims to match the quality of LeetCode's tests as closely as possible. This way, you can run everything locally, without needing for example, an internet connection.
I see the project being useful for its most straightforward purpose: testing your solutions locally on your own hardware, without any submission delays and even completely offline. Since the tests are open, people can also build different tools around them. For example vim extensions and other integrations. Ofc it's not that simple, we currently support about 1400 problems (out of 4000~, including premium), and not all topics are covered.
The fact that this is written in Haskell is amazing in it of itself. Will try it out
so the final challenge is to try to print a string ? ;)
how do you keep the local test cases in sync when the original problems or test cases change?
LeetCode problems are usually added after each contest, and as far as I know their statements generally don't change afterward at least the actual problem itself doesn't.
As for test cases, there are occasionally solutions that are technically incorrect but still pass because a particular edge case isn't covered. We maintain our own test cases, including a DSL for writing large stress tests, and try to cover all possible cases.
In the worst case, a solution might pass our local tests but fail on LeetCode. I expect such cases to be rare and one of the benefits of having the tests open is that when someone finds a missing case, it can be added so nobody else runs into the same issue.
This is awesome!