Vega: Building Vega Code Community

[nyurik]

This is a meta task to propose and discuss large code changes in order to build and sustain a coding community around Vega project. The main goal is to make new/accidental code contributors productive with the minimum efforts. This means that

• Code has to be easy to understand and follow by a newcomer with a reasonable level of coding skills.
• There should be a sufficient documentation for coders to get started and contribute
• Continuous integration should validate any new contributions, and encourage high code coverage

If the discussion for each item becomes too big, lets create a sub issue and link from here.

Proposals

• [x] Join all Vega code in the single github repo (e.g. with Lerna), while keeping sub-projects as separate NPM libs.
• [ ] Setup build system to use rollup + babel -- allows contributors to use the latest JS, while also establishing a clear support for older browsers. (e.g. declare support for Firefox version N, and babel will ensure that no newer features are accidentally used in the compiled result)
• [ ] Configure project badges to indicate build and test passing, related versions, etc
• [x] Configure code styling rules using eslint
• [ ] Configure continuous integration to
  
  
  
  • [ ] automatically compile and test all pull requests
  
  
  • [ ] check linting rules
  
  
  • [ ] show coverage results
  
  
  • [ ] show performance improvements / degradations
  
  
• [ ] Provide older version support by publishing vega-1, vega-1.5, and vega-2 npm packages.
• [ ] Migrate to classes, lambda expressions, await/asyncs (hopefully without any outside-visible changes)

[domoritz]

I agree with this proposal but would love to see us using typescript. In addition to the above benefits, we get types, .d.ts files, and schema generation.

[nyurik]

@domoritz I do agree that TS would bring additional benefits to the above. Being a strict superset of JavaScript, can TS be introduced at any point? If so, I would propose that we postpone it until all stylistic tasks are implemented first, before adding new code structures. For example, it would be good to set up proper CI to run all of the existing tests on each PR, and to establish eslint rules, etc. I think we can migrate to TS, but I don't think it blocks us from doing the above proposals.

Another thing that we still have to consider is that our goal is to attract a wide and stable community of devs. JavaScript is the lowest common denominator here, lowering the barrier of entry, while TS is an extra that some may not be very comfortable with, so I would let others express their opinions on this one. What do you think?

[saulshanabrook]

I am new to the community but am starting to need to be able to understand parts of the Vega codebase in order to write custom transforms. I would +1 the idea of switching to TypeScript (ex #1706), which can be really helpful to quickly grok a codebase without having to ask the existing maintainers lots of questions.

For example, if vega-transforms were written in Typescript, then I would have some idea what the _ and pulse arguments are for, in the filter transform. Right now I have to go hunting around in the code to see where those things are defined and see what methods are commonly called on them. If they had typings, I could let VS Code handle all that work for me :)

Migrate to classes, lambda expressions, await/asyncs (hopefully without any outside-visible changes)

This would also be very helpful, for the same reason. It would let newcomers grok the codebase more quickly.