Should General have a guideline or rule preventing registration of vibe-coded packages?

I recently registered PixelMatch.jl which is a Claude translation of a javascript library. This was an interesting case for me because this is probably the lowest-quality code I have registered. For example, the bot did some useless weird stuff with computing hashes before doing comparisons PixelMatch.jl/src/PixelMatch.jl at 522e8472871712cd83cae5de41a4d7e79ff4351e · jkrumbiegel/PixelMatch.jl · GitHub or it does a mostly useless convert into float RGBAs PixelMatch.jl/src/PixelMatch.jl at 522e8472871712cd83cae5de41a4d7e79ff4351e · jkrumbiegel/PixelMatch.jl · GitHub which loses performance.

I noticed those problems but didn’t really have time or motivation to go and fix them once the tests of the original package were passing. The package was at that point solving a real need of mine and I thought even with a bit of shoddy coding and inefficiency, it could still be useful to others. So I went ahead and registered it. I think the usefulness is the important part here, that’s the true measure of any good package.

So I support the idea that was presented further above to have a second registry where anything goes, but the General is treated as more “serious”, i.e. packages have to demonstrate usefulness before getting there. And that would mean being able to demonstrate that others have used it already for meaningful things even though it was in the second registry. I acknowledge though that this would make some things much harder or more burdensome on the maintainers.

9 Likes