This seems cool, and probably aimed at a specific use case. Maybe if you're just starting out on joining a team?

My question is if there's something I'm not seeing. How often do people have to do this for it to be a tool? Why couldn't I just check the package.json myself?

Or is this aimed at LLM's, so you can run a program instead of letting an LLM guess the tech?

package.json does not capture all the technologies in a repository. just the JS ones. This seems to capture full stack technologies. This would be very helpful when evaluating existing projects either as a consultant, new team member, open source, or evaluating a vendor's codebase or project.

yes it's one of the main use case, discovering and documenting at scale. Even on nodejs project there is more than just the package.json

Cool idea. Have we considered looking at the gitignore and gitattributes files as well? You can often figure out the IDE and other tools someone is using by looking at these.

As a counterpoint: I often see technology-specific gitignore files, created from a template, that attempt to cover all commonly used tools. Can't really tell what is actually used from that.

In my experience .gitignore files are often overloaded, so would provide false positives.

Yeah I always just put whatever in my .gitignore and never clean it up

indeed never thought of that but could be an interesting data point

I could see this being valuable for sales people

How so? Most orgs dont have their code public

Does anyone remember SpikeSource?