search

mozilla / scanjs

[DEPRECATED] Static analysis tool for javascript code.
Other
429 stars 39 forks source link

split scanjs into separate repos for nodejs, web and just the scanning #158

Closed mozfreddyb closed 2 years ago

mozfreddyb commented 9 years ago

This repo will remain the main repo for just the scanning, but we should move the web (server.js, client/) and nodejs-specific bits (scanner.js) to these repos:

@zombie agreed to work on this as a first step to familiarize himself with the existing code.

This has been a concern for a while, but not a filed issue. Thanks to @sole, who suggested that :)

sole commented 9 years ago

:+1:

zombie commented 9 years ago

so after some reading and testing with npm, dependencies, git, github and submodules, i have a slightly different proposal, based on these ideas:

  1. (assumption) users of scanjs either care about how large it is (and want only the basic lib), or they don't care at all
  2. (goal) it should be easy to use/try/deploy/contribute to the scanjs, which translates to "as few steps as possible required to start playing with it"
  3. (oppinion) we should minimize ways to mess up during development, which translates to "the fewer moving parts, the better"
  4. (fact) nodejs parts of scanjs should be usable (and probably come) with the webui part

so my suggestion is to split into just two modules, one for just the basic lib and rules (basically what's in "common" today) and then everything else. modules should be named either:

the basic lib part (i vote this to be named scanjs-core) should be included as a git submodule in the bigger one. both should be independently available for getting/using either from github or npm.

still open questions:

  1. should the basic lib module include at least some test or not
    • and if so, how should the tests run? which environment? node? browser?
    • (both options have merit)
  2. people are not unanimously in love with git submodules:
    • there are some issues with development across two different repos,
    • no shared history, not able to publish to both parts of the code-base in one commit/PR
    • needing to (remember to) update the submodule pointer on every update

but i think the benefits outweigh the potential problems, of requiring users to independently track/download/maintain dependencies and possible confusion if we ever have dev and release channels..

what do you think @mozfreddyb and @pauljt ?

zombie commented 9 years ago

also, do we want to take that opportunity to transfer the official repo?

mozilla github policy states official repos should not be forks of personal repos.