Latitude is currently designed only for internal use at Flexport. If you're not at Flexport, feel free to poke around, but we don't recommend using Latitude. (At least, not yet.)
Flexport engineers: we believe that our design system is strongest when everyone contributes. This page contains guidelines and workflow tips that should make it easy to contribute.
Latitude is versionless. It's also not published as an npm module. Instead, in the monorepo:
package.jsonfile points at the Latitude master branch on GitHubyarn.lockpins Latitude to a particular SHA
This setup aims to reduce friction for internal Latitude contributors.
You don't need to wait for a Latitude PR to be merged before beginning using it in the monorepo. It's easy to work on your Latitude and monorepo concurrently.
We will use the following tools to help sync the local repos:
brew install bindfs
brew cask install osxfuseTo set this up, point your monorepo's latitude dependency to your local repo:
bindfs -r <full_path_to_latitude_repo> <full_path_to_monorepo>/node_modules/latitude
# the first time you run this, you will have to go into Mac System Preferences to enable its kernel extensionTo go back to the original version of latitude:
umount <full_path_to_monorepo>/node_modules/latitude
# NOTE: if you try running yarn install before going back to the original version of latitude, it will fail!It is recommended you set up aliases for the above commands if you want to follow this flow
An alternative approach that uses less setup is to use yarn link. However this has been known to cause Flow issues where Flow will evaluate Latitude components in monorepo. Restarting the Flow server generally resolves this.
cd location/of/latitude
yarn link # adds Latitude to the link registry
cd location/of/flexport
yarn link latitude # links Latitude module to the Latitude in the link registrycd location/of/flexport
yarn unlink latitudeAfter unlinking you should run yarn install --force so that your node_modules folder are back to what they should be.
cd location/of/latitude
yarn unlinkWe are currently working on improving development workflow. You can keep track of progress in this JIRA issue: LDS-531.
If you are actively developing, the recommended workflow is to have tests and storybook running in the background in separate terminals. This should provide you with realtime feedback:
yarn jest --watch
yarn storybookBefore you submit a pull request, check that it meets these guidelines:
- If your pull request fixes a bug, it should include tests that fail without the change, and passes with them.
- If your pull request adds functionality, update all relevant documentation (component doc blocks, prop doc blocks, etc). Don't forget tests.
- Pull requests that introduce breaking changes should be accompanied by a monorepo pull request that updates all call-sites.
Most contributors will need to setup a personal fork to be able to open pull requests. If you directly clone this repository it will reject your pushes unless you are an owner.
Note: your fork will not automatically sync with the main repository. Make sure you keep it updated with git pull upstream master.
- Fork the repository - notice the "Fork" button at the top of the page
- Clone your personal version of the repo into your machine
git clone [email protected]:<YOUR GITHUB USERNAME>/latitude.git- Set the upstream repository
git remote add upstream https://github.com/flexport/latitude.git- Commit your change
git commit -m "<COMMIT NAME>"- Fetch latest
git fetch upstream- Rebase to latest on the main repository
git rebase upstream/master- Push up your branch to your fork
git push origin <BRANCH NAME>- Open Github and open the pull request