Launch HN: DeepSource (YC W20) – Find and fix issues during code reviews

  • > Enable analyzers by adding .deepsource.toml

    Why is this needed? Can't you imply the necessary analyzers from my codebase?

    There is no support for Javascript, Typescript, PHP, Java or C#. No HTML or CSS support. Is there a roadmap?

    Also, the name implies use if Deep Networks and AI. Am I mistaken? If not, what kind of AI is used here? Seems like just an automatic runner of static analysis tools.

  • There's a better solution: use open-source cli tools that do just that!

    1. 520 Python checks? Use `wemake-python-styleguide` (wrapper around flake8) that has bigger amount of checks: https://github.com/wemake-services/wemake-python-styleguide There's also `pylint` with a set of awesome checks as well.

    2. Type checking? Use `mypy`: it just a single command!

    3. Autofixing? Use `black` / `autopep8` / `autoflake` and you can use `pybetter` to have the same ~15 auto-fix rules. But, it is completely free and open-source

    I don't like this whole idea of such tools (both technically and ethically):

    - Why would anyone want to send all their codebase to 3rd party? We used to call it a security breach back in the days

    - On moral side, this (and similar) projects look like thin wrappers around open-source tools but with a monetisation model. How much do these companies contribute back to the original authors of pylint, mypy, flake8? Ones who created and maintained them for years. I will be happy to be wrong here

  • Congrats on the HN launch guys :) Excited to see Javascript being added to the list of supported languages soon.

  • How is this different (or better?) than existing products that offer the same service, such as Codacy.

    Have been a paying customer of Codacy’s for ~2 years and they support most languages out of the box at this point, with Git integration similar to your own.

    Curious on your thoughts.

  • Congratulations on the launch! Have been following the team's progress for a while and truly impressed with the pace of feature development while keeping the core product extremely simple. Happy to be a customer.

  • This looks awesome - congrats on the launch.

    Quick question: I tried setting it up but its asking for Write access to the pull requests. I am a bit wary about giving write access - is this required?

  • This is a serverside pre-PR hook for an analyzer, as I understand it.

    I was hoping this was a code review tool that allows you to modify the PR without making a commit-merge-push loop, which could have approved changes automagically pulled locally (for the loop). This would save a TON on small edits that many PRs require, including any additional comments that people might want to add to code that come up during PR...modern PRs is where context goes to die.

  • So our CI pipelines are always set up so that failed linting means blocked merge capability. Your PR isn't ready for review if it's failing rubocop for example. Do you intend to integrate your tool into this type of workflow but by making the lint issues apparent via comment on the PR in GitHub vs in the CI?

  • Cool! Can you provide some real world examples of issues you flag? I poked around on your site and didn’t see any.

  • Is there a list of the open source static analysis tools that you are using? Do you have any proprietary tools you have written?

  • When you offer support for C++, we'll talk. More challenging to parse and analyze, of course.

  • Congrats! Any plans to add support for more languages?