
Show HN: How to ensure JavaScript code quality - wschoi
https://deepscan.io/home/
======
donatj
Our JavaScript at this point is basically an add only nightmare I have no idea
how to dig ourselves out of.

It is a bigger problem than I know how to fix. We even have a similar static
analysis tool on our code, but when there are thousands and thousands of
existing issues pointed out by it no one really cares about adding a few more
to the pile.

I tried to promote typescript and rewriting over time. I can’t seem to get our
front end developers to understand the value, or care. It’s totally my
failure; it hurts my soul.

It’s honest to god something of an existential crisis for me.

I hunkered down in primarily backend over the nightmare that is our JS,
whereas I spent nearly ten years full stack. Sigh.

~~~
kozak
Here is the method I used in a similar situation. Start from an extremely
loyal linter config where you get 0 errors and 0 warnings with your existing
code (that might mean an empty config, but that's OK). Then add rules one by
one, fixing the codebase completely for each rule that you add, so that you
always have 0 warnings and 0 errors with each commit. Yes, this is significant
amount of work, but at least the work is broken down into chunks, and each
chunk has a clear definition of done (can go straight into an agile backlog,
etc). By the time you have a sensible linter config, you have a much better
codebase as well.

~~~
aizatto
Ditto, this is the same thing I did for a 16,000+ line app.

I used eslint ( [https://eslint.org](https://eslint.org) ) and prettier (
[https://prettier.io](https://prettier.io) ), and using airbnb's JavaScript
Style Guide as a reference point (
[https://github.com/airbnb/javascript](https://github.com/airbnb/javascript)
), I would enable rules one by one. Then slowly rule by rule (commit by
commit) I would clean up the code base.

~~~
_pdp_
Our modules currently are at 96398 lines of code (I am not counting the apps).
It is still maintainable and perfectly understandable. Everything is split
into module though and then every module has its own tests and its own
examples. We lack proper documentation. It is not a problem yet but it could
turn out to be in the future.

------
dotmanish
Thanks for clearly answering the privacy + security related questions (I
specifically went to the site to search for this - way too many software
dealing with your code forget to specify this):

 _" For demo and editor plugins, we store the source content transmitted to
the server as a temporary file. Right after the inspection, the file is
completely deleted."_

~~~
tyingq
That is laudable and refreshing. Since they are being so upfront, though, it
would be nice to spell out that no copies or derivitive metadata are kept
either.

~~~
wschoi
Thanks for the comment. We will add those facts to documents in the next
release, which is planned on the end of this month.

------
sharpercoder
Just tried it out. Smooth sailing! A couple remarks: 1) It would be nice to
explain some of the warnings. I had

    
    
        myFunction() {
            for (var x in xs) { .. }
            for (var x in xs2) { .. }
        }
    

it would complain about "Duplicate declaration of variable 'x'".
Understandable, but then I'd like to know the javascript context information
(apparently x is not in a sub-scope (as in most languages), but in the main
function scope). 2) GitHub integration would be nice. A button when looking at
source in GitHub which annotates the code with warnings would be quite an
improvement over the current view.

~~~
wschoi
Thanks for the helpful comment!

1) We will consider adding explanation like "Note that 'x' is declared in
function scope. Consider using 'let' declaration if you intended block scope".

2) Yes. Directly showing warnings in the GitHub site would be a nice feature.
We will consider it in our roadmap.

------
shamas
I'm not sure what advantage this has over Flow and the usual JIRA ticket
management.

~~~
wschoi
DeepScan runs data-flow analysis that is somewhat orthogonal to the type
checking of Flow.

For example, BAD_MIN_MAX_FUNC rule detects an error in the following code,
which is beyond type checking.

    
    
      x = Math.min(0, Math.max(100, x)); // BAD_MIN_MAX_FUNC alarm. The result is always 0.
    
    

The main diffrenece with JIRA ticket management is that it operates using
information from code itself.

For example, it automatically tracks fixed and newly detected issues by a
feature called historical defect merging.

------
tootie
We're running Sonar in our enterprise so this is an attractive integration.
Currently it's reporting all sorts of stuff on our Java codebase that the team
seems to be ignoring. Anyone have good tips on enforcing compliance?

~~~
ivanche
Make the build fail if Sonar fails. Whoever breaks the build must fix it.

------
DiThi
I've tried it with a bunch of files of an open source project of mine. It's in
coffee script 2 so I've converted it to ES6 first. It has found many minor
problems, and a couple of potential bugs. Definitely useful!

------
j0k3r
Where is the pricing page? Is it free?

~~~
Dolores12
from [https://deepscan.io/getting-started/](https://deepscan.io/getting-
started/)

Pricing

We are in BETA stage and do not provide paid plans yet.

But open source projects are free and one private project is for your trial
experience.

If you're interested in using DeepScan for more private projects, please
contact us.

~~~
j0k3r
Ok thanks! I was looking for a pricing page in fact :)

------
_pdp_
Does it catch security problems because this code returned 0 issues?

    
    
      var lave = eval(atob(document.location.hash.slice(1)))    
      console.log(lave.name)

~~~
wschoi
No. DeepScan concentrates on runtime errors and does not cover security issues
currently.

------
redkoala
Is it possible to run this as a npm package against local Git repositories? Or
is that in the roadmap?

~~~
wschoi
We have a npm cli pacakage but currently provide it to limited partners only.
In the future, we are considering to include it under paid plan.

------
fiala__
looks interesting. What are the advantages of running such analysis on GitHub
rather than locally?

~~~
throwaway899
It mentions 'Editor Plugins' on the page so I suppose you can run this locally
too.

One Advantage I can think of of running such analysis on GitHub would be
automatically analyzing pull requests.

------
dnate
So this is only available for github projects? Any plans on including others?

~~~
wschoi
We are planning to support Bitbucket and GitLab in long term.

You can check out more detail in [https://deepscan.io/docs/get-
started/basics/#non-github](https://deepscan.io/docs/get-started/basics/#non-
github)

------
golergka
Curious, how does this compare to a statically typed language compiler?

~~~
wschoi
While DeepScan finds some type-related errors, it focuses on finding issues
orthogonal to type checking.

For comparison with Java, DeepScan is like FindBugs.

Check the reply that I have wrote for shamas.

------
agnivade
Dang, my projects are in gitlab. Any word on gitlab integration ?

~~~
wschoi
Sorry, no gitlab integration yet. It is on the next year roadmap.

In the meantime, you can try editor plugins if you are using Visual Studio
Code or Atom.

Check [https://deepscan.io/docs/get-started/basics/#non-
github](https://deepscan.io/docs/get-started/basics/#non-github) for details.

------
z3t4
Write a guide on how to integrate it into an editor!

~~~
wschoi
If you are using Atom or Visual Studio Code, you can try the following
plugins:

\- Visual Studio Code:
[https://marketplace.visualstudio.com/items?itemName=DeepScan...](https://marketplace.visualstudio.com/items?itemName=DeepScan.vscode-
deepscan)

\- Atom: [https://atom.io/packages/atom-
deepscan](https://atom.io/packages/atom-deepscan)

------
dzonga
kinda useful from the one file I tried!!

------
VesnaOgneva
interesting tool

