Welcome to the Vega community. Everyone is welcome to contribute. We value all forms of contributions including code reviews, patches, examples, community participation, tutorial, and blog posts. Int this document, we outline the guidelines for contributing to the various aspects of the project.
If you find a bug in the code or a mistake in the documentation or want a new feature, you can help us by creating an issue to our repository, or even submit a pull request.
-
For small fixes, please feel free to submit a pull request. Don't worry about creating an issue first.
-
For major changes, please discuss it with the community via a GitHub issue first. This will help us coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.
- One way to use GitHub for this purpose is to submit a pull request (PR) with a ":construction: WIP" (work in progress) label.
-
Generally we name a branch using this pattern
<your 2-3 letters initial>/<topic>
. For example, @kanitw's branch regarding scale type might be calledkw/scale-type
.
See our issue and pull request templates for more information.
You can find tasks with the ":pray: Help wanted" label in the issue tracker. Please add a comment in an issues if you are planning to work on a major task.
To submit a new example, fork our example Block and send us a pull request to add a link to it to our example gallery.
The website is under site/
and the documentation is under site/docs/
. We use Github Pages to publish our documentation when we release a new version. To contribute changes to the documentation or website, simply submit a pull request that changes the corresponding markdown files in site/
.
Since we only publish the Github Pages when we release a new version, it might be slightly outdated compared to master
. For development, once you have setup the repository, you can run yarn site
to serve the github page locally at http://localhost:4000/vega-lite/.
Note that when you checkout different branches, the compiled JavaScript for the website might be reset. You might have to run yarn build:site
to recompile the JavaScript so that interactive examples work.
General Guides for Markdown Files:
- Wrap properties (
key
) with back ticks. - Wrap values with back ticks for numbers and booleans (e.g.,
5
,true
) and wrap string values with both back ticks and double quotes ("red"
).
To generate a property tables from the JSON schema (which is in turn generated from the Typescript interfaces, you can include the table.html
template. For example, to generate a table that includes rangeStep
, scheme
, and padding
from Scale
, you can use
{% include table.html props="rangeStep,scheme,padding" source="Scale" %}
To define a link for types in the table, you can edit _data/link.yml
.
For JSDocs comment in the interfaces, please add __Default value:__
line at the end to describe the property's value.
To include an example specification in the documentation, the specification's .vl.json
file must be in examples/specs
. Then you can use the following span tag to include the specification (e.g., for point_1d.vl.json
):
<span class="vl-example" data-name="point_1d"></span>
Before adding a new example, you might want to search inside examples/
folder to see if there are other redundant examples that you can reuse.
To name the example file:
- Please begin with mark type and follow by some description for a static single view example. For stacked marks, add
stacked_
prefix. - For composite views, please begin the file with the operator name (e.g.,
layer
). - For interactive example, begin with either
interactive_
orselection_
. - For examples that are only for regression test, begin with
test_
.
After you push a new branch to GitHub, Travis will automatically run yarn build:examples
to recompile all examples and push the changed Vega specs and SVG files in examples/compiled
, so that your branch includes these changes. When you add a new example or update the code, you may run yarn build:examples
or yarn build:example <examplename>
(e.g., yarn build:example bar_1d
) to see the change locally. However, do not include these changes in your commit as different systems produces slightly different SVGs (mainly due to floating point differences). To avoid unnecessary SVG diffs, we should just let Travis always generate the images. You're still encouraged to run yarn build:examples
to make sure that your code does not cause unnecessary changes.
Notes:
yarn build:examples
only re-compile SVGs if the output Vega file changes (so it runs way faster). If you want to enforce re-compilation of all SVGs, useyarn build:examples-full
.- To make Travis run
yarn build:examples-full
, include[SVG]
in your commit message of the last commit in your branch. - To run
yarn build:examples
, you need to install gnu parallel. (For Mac,you can simply dobrew install parallel
.)
brew install node
- Clone this repository and cd into your local clone of the repository, and install all the npm dependencies. We use yarn to have reproducible dependencies:
git clone https://github.com/vega/vega-lite.git
cd vega-lite
yarn
Now you should be able to build and test the code.
For ruby, Mac users can use homebrew to add it:
brew install ruby
For bundler:
gem install bundler
For jekyll and its dependencies, because we already have the Gemfile
in the repo, you can simply run:
bundle install
-
_layouts/
– Our website and documentation's Jekyll layout files. -
bin/
– Scripts for using Vega-Lite with command line. -
data/
– Example data. -
site/
– Vega-Lite website including documentation. -
examples/
– Example Vega-Lite specifications.specs
Vega-Lite examples.compiled
The generated Vega specifications and SVG files of the Vega-Lite examples.
-
scripts/
- Scripts for NPM commands. -
src/
- Main source code directory.- All interfaces for Vega-Lite syntax should be declared at the top-level of the
src/
folder.src/index.ts
is the root file for Vega-Lite codebase that exports the globalvl
object.- Other files under
src/
reflect namespace structure. All methods forvl.xxx
will be in eithersrc/xxx.ts
orsrc/xxx/xxx.ts
. For example,vl.channel.*
methods are insrc/channel.ts
whilevl.compile
is insrc/compile/compile.ts
.
- All interfaces for Vega-Lite syntax should be declared at the top-level of the
-
test/
- Code for unit testing.test
's structure reflectssrc
's directory structure. For example,test/compile/
tests files insidesrc/compile/
. -
test-runtime/
- Code for runtime tests. You can debug the tests by running puppeteer in debug mode. -
typings/
- TypeScript typing declaration for dependencies.
- The main compiler code is in
src/compile/compile.ts
. To try to understand how Vega-Lite works, first start by reading thecompile
method in the file and try to understand different phases in the compilation process. You can browse the code online with Sourcegraph.
This section lists commands that are commonly used during development. See package.json
for other commands.
You can run yarn build
to compile Vega-Lite and regenerate vega-lite-schema.json
.
yarn test
run linting and all unit-tests respectively. yarn format
automatically fixes linting issues if possible. yarn test:inspect
to inspect tests
yarn test
includes test coverage and generates a report inside coverage/index.html
. You can see if specific lines are covered in the unit test by running open coverage/index.html
and browsing through the report.
During development, it can be convenient to rebuild automatically or to run tests in the background. You can use:
-
yarn watch:test
to start a watcher task that lints and runs tests when any.ts
file changes. -
yarn watch:build
to start a watcher task that re-compiles Vega-Lite when.ts
files related to VL change.
yarn site
. See details in Documentation and Website.
(For team members only) yarn deploy
will publish latest code to NPM and also update github pages, which contains our webpage and documentation. If you want to update only github pages, use yarn deploy:gh
.
We use the Visual Studio Code editor.
- VSCode has nice built-in Typescript support!
- We already include project settings to hide compiled files (
*.js
,*.js.map
). This should work automatically if you open thevega-lite
folder with VSCode. - Make sure to install TSLint, Prettier extensions.
- The vscode-jest-runner extension is also very helpful for debugging tests.
To manually test your changes locally, you should have a local instance of Vega Editor and link Vega-Lite to the editor (See Vega Editor's README for instructions).
All pull requests will be tested on Travis. If your PR does not pass the checks, your PR will not be approved. Travis' environments will run yarn test
, generate vega specs and SVG files from your updated code, compare them with the existing compiled outputs in examples/compiled/
, and check code coverage of your code. (See .travis.yml
for the commands it executes.) If you don't want your PR reviewed until Travis checks pass, just add the ":construction: WIP" label. Once you're ready for review, remove the label and comment that the PR is ready for review.
When checking for code coverage, we require that your PR tests cover at least the same percentage of code that was being covered before. To check the code coverage, you can see the link in the job log of your Travis test, from the Github page of your PR, or on https://codecov.io/gh/vega/vega-lite/commits
. It'll be usually in the form of https://codecov.io/gh/vega/vega-lite/commit/your-full-head-commit-number
. Under the Files and Diff tab, you can check your code coverage differences and total. In Files, you can check which lines in your files are being tested (marked in green) and which are not (marked in red). We appreciate PRs that improve our overall code coverage!