This directory contains development guidelines for deck.gl.
Some of these documents may also be referenced by other repositories in the stack of open source components of vis.gl:
- react-map-gl
- luma.gl
- loaders.gl
- viewport-mercator-project
- mjolnir.js
- math.gl
- probe.gl
For instructions to set up the dev environment, see developing deck.gl.
Any new deck.gl feature must start with a GitHub issue. The issue will be used to track the discussion, planning (milestone), implementation (PRs) and release of the feature.
Non-trivial new features should typically be proposed with an RFC (Request for Comments) to make sure we have a complete story before making big modifications to the code base. It also allows the bigger team (as well as the community) to stay engaged, comment and contribute insights. See RFC Guidelines.
A small, non-disruptive feature may be implemented without an RFC. The tracking issue should instead describe the background and the proposed change.
All proposals will be reviewed and approved by the team before implementation. User-facing API changes should be audited following the API Guidelines. Breaking changes are scheduled for appropriate releases according to the Deprecation Guidelines.
Follow Code Guidelines when making changes to the source code.
New code must be covered by tests. We have created a suite of tools that enable unit tests for JavaScript and GLSL shaders, and integration tests for WebGL rendering and user interaction. See Test Guidelines.
Additional testing could be done with the layer browser application, including the combination of prop values, transitions, etc. Changes to the WebGL rendering pipeline must be tested for additional browsers, see supported platforms.
Documentation should be updated to reflect the changes made to user-facing behavior and APIs. This includes the API documentation for the modified component, tutorials, advanced articles, and the What's New and Upgrade Guide pages.
All code changes should open PRs on GitHub and be approved by at least one other team member. If the master branch and the current release branch have diverged, a separate PR may be needed to patch the release branch.
Our frameworks follow the Semantic Versioning guidelines.
- Patch release: bug-fixes that unblock the usage of the current minor release.
- Minor release: backward-compatible feature additions, dependency changes, and bug fixes that result in behavioral/visual changes.
- Major release: breaking API changes.
See branching and releasing model for how we track the code changes cross releases.
Follow the publish checklist when publishing a new release to npm.