To get started:
git clone [email protected]: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 | Description |
---|---|
npm run bootstrap | Install dependencies and link local packages. |
npm run build | Build all packages. |
npm run watch | Watch all packages for rebuilds. |
npm run test | Run tests for all packages. |
lerna run build --scope <package> | Build only <package>. |
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:
git clone
or simply copy the project into thepackages/@testing
folder. Everything in this folder is ignored by git.- In the root of the monorepo, run
npm run bs
to link the necessary development packages - 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 abuild
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 runninglerna run build --ignore=YOUR_PACKAGE_NAME
or adding the name of your package to theignore
array for therun
command inlerna.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.
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
next
is merged intolatest
; thenlatest
is published to npmmaster
is merged intonext
; thennext
is published to npm
- Any hot fixes for bugs will be cherry picked into
next
andlatest
and the published accordingly. - Every pull request merged to
master
automatically triggers acanary
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
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!