@carto/kepler.gl

CARTO fork of Kepler.gl

Published as @carto/kepler.gl, used by the Cloud Native app.

Development process

Pull request

• Each development should be done in its own feature branch

• The pull request should be diff-ed with the main branch

• Apart from code changes, the PR should include an entry in the "Not released" section of CHANGELOG.md with a link to itself (if the section is not present, re-create it at the top of the file). This facilitates the release process by keeping the changelog always up-to-date with main.

  Ex:

  ## Not released
  
  - Support for count aggregation [141](https://github.com/CartoDB/carto-kepler/pull/141)

• After review, merge into the main branch by squashing commits, to keep a clean history.

Developing with Cloud Native

When developing locally, you can use symlinks to connect your local Cloud Native to your local CARTO Kepler:

1. in carto-kepler: yarn link
2. in cloud-native: yarn link @carto/kepler.gl
3. in carto-kepler: yarn build:watch
4. in cloud-native: yarn start

Dev prerelease

To be able to test a dev version of carto-kepler from cloud-native on a remote environment (ex: dedicated environments for QA), you need to publish an alpha version of carto-kepler.

1. Switch to the branch you want to publish. You can use any unmerged dev branch, but make sure it's based on the latest main to avoid behavior changes outside the branch scope.

2. Manually change the version in package.json. Use this pattern: <next-version>-alpha.<feature>.

   Ex: 0.0.47-alpha.custom-markers

3. Build the project with yarn build, and ensure there is no error.

4. Publish the package to NPM as alpha. You need to have the proper rights on the NPM organization.

   npm publish --tag alpha
   

5. If the package has been correctly published, then in cloud-native install the new version with yarn add @carto/kepler.gl@<alpha-version-number>, and open a PR.

If you need to change some things later in the code, you will need to republish. Repeat the process by simply adding a suffix to the version number.

Ex: 0.0.47-alpha.custom-markers.2

Stable release process

1. Create a branch release-<next-version> from the latest changes on main.

2. Modify the CHANGELOG.md file, by creating a new section <next-version> and moving contents from "Not released" to it. Keep the empty "Not released" section at the top of the file.

3. Increase version in package.json to <next-version>

4. Build the project with yarn build, and ensure there is no error.

5. Commit the changes (git commit -am "release <next-version>"), push, open a PR, ask for review and merge.

6. Finally change to the main branch and publish to NPM

   npm publish --access public