• ramon156 a day ago |
    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?

    • manvillej a day ago |
      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.
      • h1fra 18 hours ago |
        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
  • ripberge a day ago |
    I could see this being valuable for sales people
    • AznHisoka 15 hours ago |
      How so? Most orgs dont have their code public
  • bob1029 20 hours ago |
    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.
    • h1fra 18 hours ago |
      indeed never thought of that but could be an interesting data point
    • fuzzy2 16 hours ago |
      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.
    • JoBrad 16 hours ago |
      In my experience .gitignore files are often overloaded, so would provide false positives.
      • dartos 12 hours ago |
        Yeah I always just put whatever in my .gitignore and never clean it up
  • jasebell 14 hours ago |
    Does anyone remember SpikeSource?