ericholiveira
Joined 11 years ago
Karma
31
Submissions
16
Member since
Oct 6
Recent submissions
Comment · 5 days ago
Heard your feedback on improving UX/UI for the final artifact and just updated it... Thank you all, and would love to hear more feedbacks
Comment · 5 days ago
exactly, that is the objective
Comment · 5 days ago
Thank you... good to know youre sensing the same problem
Comment · 5 days ago
Ive taken your feedback in consideration, and recreated UX/UI for the artifact, would love to hear your feedback on it
Comment · 5 days ago
It dont uses LLM to give score.. the score is based on static analysis only, based on some criterias:
- Dependency graph of the code (the more is central on the graph, the riskier is the change)
- If it have any obvious flaws (security, lint, breaking API Changes)
- Test coverage of diff lines
Comment · 5 days ago
Thank you for the feedback, ive just updated the UI... would love to hear if you feel it improved it
Comment · 6 days ago
I do agree those kinds of tools are needed... great to know youve been working on something similar
Comment · 6 days ago
Thanks... it surely is possible to try to reduce the amount of information
Comment · 6 days ago
Thats is surely true... i did it with AI and i do lack design skills
Comment · 6 days ago
It suggested based on the files most used (through graph dependency), for this reason it appears as a important file (as if it breaks, it can break several places in your codebase), but that being said, you can add some files to be ignored (if you have special files, like consts or i18n)
Comment · 6 days ago
Hi HN, I built farol at Winnin, where we open-sourced it (MIT).
AI agents now write a lot of our code, and AI reviewers catch a lot of the line-level problems. But someone still has to press "merge", and that person has the same question every time: how risky is this, and where should I spend my attention? A 40-file PR where 38 files are isolated is very different from a 3-file PR that changes a model used by 23 endpoints.
farol is a CLI (and a GitHub Action) that answers that statically:
- classifies the PR (global / touches-existing / isolated / unknown) and gives a 0-100 merge risk score - ranks the files by risk and says why: what each one reaches (routes, endpoints, jobs), contract breaks in API responses, dependency changes, security patterns - diff coverage from your existing coverage report, so "38% of the changed lines are tested" sits next to the risky files - an HTML report where you mark files as reviewed and the score and test plan follow; incremental mode for "what changed since my last review"; suggested reviewers from git blame
How: it uses the TypeScript compiler API for TS/React (React Router, Next.js, TanStack Router) and TS backends, a small go/types helper for Go, and Python's ast for FastAPI/Flask/Django and friends. No LLM, no network during analysis, and it never executes the analyzed repo's code. It's deterministic and informs only; it never blocks a merge.
Live demo (two reports from a real PR, nothing to install): https://winnin.github.io/farol/demo/
Try it on a branch: npx @winninjs/farol --help
Limitations: only TS, Go and Python for now, and the reachability is static, so dynamic dispatch and reflection make it fail closed ("unknown") rather than guess. I'd love feedback on the risk score and on false positives in your codebase.
Comment · 10 years ago
I've been working for a while in this framework and using it in production in the company i work for. It enforces good pratices of service design in node js, and make it really simple to use. With his plugin system you can even distribute you services across different machines, without changes in your code among other options like timeout and retries on services and reatime metrics.