@tinacms/styles v0.42.1

Getting Started

• Website
• Documentation
• Roadmap
• Contributing
  • How to Contribute
  • Creating Packages
  • Troubleshooting in Development
• Release Process

Development

To get started:

git clone git@github.com:tinacms/tinacms.git
cd tinacms
npm install && npm run bootstrap
npm run build

# Start Gatsby demo
cd packages/demo-gatsby
npm run start

Do not run npm install from inside the packages directory

TinaCMS uses Lerna to manage dependencies when developing locally. This allows the various packages to reference each other via symlinks. Running npm install from within a package replaces the symlinks with references to the packages in the npm registry.

Commands

Testing With External Projects

Currently, testing with external projects is somewhat inelegant, but this repo includes a folder designed for importing external projects into the monorepo so the development versions of Tina packages can be bootstrapped into the project. To import an external project:

1. git clone or simply copy the project into the packages/@testing folder. Everything in this folder is ignored by git.
2. In the root of the monorepo, run npm run bs to link the necessary development packages
3. Navigate to your project folder and develop normally

Pitfalls of Testing with External Projects

• Running npm run build in the root of the monorepo will run a build script if your project has one defined. If this causes problems (tina may be causing your build to fail in the first place, and you want to skip the build for now but still build the other packages,) you can get around this by either running lerna run build --ignore=YOUR_PACKAGE_NAME or adding the name of your package to the ignore array for the run command in lerna.json.

//lerna.json
{
  "command": {
    "run": {
      "ignore": ["YOUR_PACKAGE_NAME"]
    }
  }
}

• Gatsby and React both rely on some globally-persisted values which can cause errors if you have multiple copies of these dependencies installed. When testing a Gatsby site, many issues can be worked around by temporarily deleting the demo-gatsby package and bootstrapping again.

Release Process

Tina has three main branches:

• master: The bleeding edge of tinacms
• next: A preview of the next release
• latest: The current stable release

The flow of changes therefore looks like:

fix-some-bug => master => next => latest

The process happens over a week:

• On Monday
  1. next is merged into latest; then latest is published to npm
  2. master is merged into next; then next is published to npm
• Any hot fixes for bugs will be cherry picked into next and latest and the published accordingly.
• Every pull request merged to master automatically triggers a canary release.

With this process:

• all accepted changes are available as canary releases for early testing
• critical fixes are published as soon as possible
• new features and minor fixes take ~1.5 weeks to be published

Contributors ✨

Thanks goes to these wonderful people (emoji key):

This project follows the all-contributors specification. Contributions of any kind welcome!