@tinacms/cli 0.60.23 → 0.60.26

package/CHANGELOG.md

@@ -1,1190 +0,0 @@
-# tinacms-cli
-
-## 0.60.23
-
-### Patch Changes
-
-- Updated dependencies [3325cd226]
-  - @tinacms/graphql@0.60.8
-
-## 0.60.22
-
-### Patch Changes
-
-- b1a4290e6: Use media config from the schema in the local media server
-- 1955b8842: Uses new `schema.config` when resolving media/asset urls
-- Updated dependencies [f6cb634c2]
-- Updated dependencies [b1a4290e6]
-- Updated dependencies [1955b8842]
-- Updated dependencies [8b81c3cf3]
-  - @tinacms/graphql@0.60.7
-  - @tinacms/schema-tools@0.0.5
-  - @tinacms/datalayer@0.1.1
-  - @tinacms/metrics@0.0.3
-
-## 0.60.21
-
-### Patch Changes
-
-- Updated dependencies [e2aafcd93]
-- Updated dependencies [a20fed8b7]
-  - @tinacms/graphql@0.60.6
-
-## 0.60.20
-
-### Patch Changes
-
-- f71f55ac3: Fixd issue where --dev caused a breaking change
-- Updated dependencies [57f09bdd7]
-  - @tinacms/graphql@0.60.5
-
-## 0.60.19
-
-### Patch Changes
-
-- d103b27ad: Fix issue where new collections would not be added when CLI restarts
-- e06dbb3ca: Adds `waitForDB` cmd to cli
-- Updated dependencies [d103b27ad]
-  - @tinacms/graphql@0.60.4
-
-## 0.60.18
-
-### Patch Changes
-
-- 79d112d79: Update cli to accept tinaCloudMediaStore flag and add to metadata during schema compilation
-- 91d6e6758: revert platform aware paths in schema introduced in https://github.com/tinacms/tinacms/commit/558cc4368cd2a4b6e87dfb82bbfbb6f569f8a6f8
-- b1240328d: Adds local server routes for handling media
-- 91d6e6758: Fix issues with experimentalData on windows related to path separator inconsistency and interference with the .tina/**generated** folder
-- Updated dependencies [79d112d79]
-- Updated dependencies [3f46c6706]
-- Updated dependencies [db9168578]
-- Updated dependencies [91d6e6758]
-  - @tinacms/graphql@0.60.3
-
-## 0.60.17
-
-### Patch Changes
-
-- 08cdb672a: Adds `useRelativeMedia` support to local graphql client
-- 646cad8da: Adds support for using the generated client on the frontend
-- f857616f6: Rename sdk to queries
-- Updated dependencies [08cdb672a]
-- Updated dependencies [fdbfe9a16]
-- Updated dependencies [6e2ed31a2]
-  - @tinacms/graphql@0.60.2
-  - @tinacms/schema-tools@0.0.4
-
-## 0.60.16
-
-### Patch Changes
-
-- 7372f90ca: Adds a new client that can be used on the backend and frontend.
-- Updated dependencies [3b11ff6ad]
-  - @tinacms/graphql@0.60.1
-
-## 0.60.15
-
-### Patch Changes
-
-- ceb826916: Fix issue where \_app override from tina init was improperly formatted
-
-## 0.60.14
-
-### Patch Changes
-
-- Updated dependencies [6a6f137ae]
-  - @tinacms/graphql@0.60.0
-
-## 0.60.13
-
-### Patch Changes
-
-- 9d28ea29e: hide some existing start:server logging behind --verbose flag. format some messages to make them easier to read
-
-## 0.60.12
-
-### Patch Changes
-
-- ef450a53a: - Update tinacms CLI to support schemaFileType option (default 'ts') to allow user to specify the schema file type
-  - Update telemetry module to optionally check NO_TELEMETRY environment variable for disabling telemetry
-- 81b729c24: Update formatting of cli init outputs
-- 558cc4368: Make schema init platform-aware and refactor database put requests
-- Updated dependencies [4da32454b]
-- Updated dependencies [921709a7e]
-- Updated dependencies [ef450a53a]
-- Updated dependencies [a2906d6fe]
-- Updated dependencies [558cc4368]
-- Updated dependencies [06666d39f]
-- Updated dependencies [3e2d9e43a]
-  - @tinacms/graphql@0.59.11
-  - @tinacms/schema-tools@0.0.3
-  - @tinacms/metrics@0.0.3
-  - @tinacms/datalayer@0.1.1
-
-## 0.60.11
-
-### Patch Changes
-
-- Updated dependencies [cf33bcec1]
-  - @tinacms/graphql@0.59.10
-
-## 0.60.10
-
-### Patch Changes
-
-- 6154d12b8: Check for appropriate versions of react and react-dom before initializing with tinacms init
-- 8c23d69a2: Adds an MDX example when you run @tinacms/cli init
-- abf25c673: The schema can now to used on the frontend (optional for now but will be the main path moving forward).
-
-  ### How to migrate.
-
-  If you gone though the `tinacms init` process there should be a file called `.tina/components/TinaProvider`. In that file you can import the schema from `schema.ts` and add it to the TinaCMS wrapper component.
-
-  ```tsx
-  import TinaCMS from 'tinacms'
-  import schema, { tinaConfig } from '../schema.ts'
-
-  // Importing the TinaProvider directly into your page will cause Tina to be added to the production bundle.
-  // Instead, import the tina/provider/index default export to have it dynamially imported in edit-moode
-  /**
-   *
-   * @private Do not import this directly, please import the dynamic provider instead
-   */
-  const TinaProvider = ({ children }) => {
-    return (
-      <TinaCMS {...tinaConfig} schema={schema}>
-        {children}
-      </TinaCMS>
-    )
-  }
-
-  export default TinaProvider
-  ```
-
-- Updated dependencies [8b3be903f]
-- Updated dependencies [82174ff50]
-- Updated dependencies [a87e1e6fa]
-- Updated dependencies [abf25c673]
-- Updated dependencies [591640db0]
-- Updated dependencies [e8b0de1f7]
-- Updated dependencies [b01f2e382]
-  - @tinacms/datalayer@0.1.0
-  - @tinacms/graphql@0.59.9
-
-## 0.60.9
-
-### Patch Changes
-
-- 048538625: fix: return cms on cmsCallback codegen (to fix broken typing)
-- Updated dependencies [e7b27ba3b]
-- Updated dependencies [11d55f441]
-  - @tinacms/graphql@0.59.8
-
-## 0.60.8
-
-### Patch Changes
-
-- 919f5cb6c: use standard next script names
-
-## 0.60.7
-
-### Patch Changes
-
-- 9e436f145: Update CLI to use defineConfig
-- 851e4be73: Update tina init to use the new way of laying out tina config
-- cc99e4309: update admin file path to /pages/admin.js to support the hash router
-  - @tinacms/datalayer@0.0.2
-  - @tinacms/graphql@0.59.7
-  - @tinacms/metrics@0.0.2
-
-## 0.60.6
-
-### Patch Changes
-
-- 98622111d: Use [esbuild](https://esbuild.github.io/) to build the schema instead of typescript.
-
-  This allows the user to
-
-  - use non typescript files like JS, JSX, TS
-  - Import from outside of the tina folder
-
-  The downside
-
-  - Now type errors will still pass (The schema will compile) and one will get an error at runtime instead of compile time
-
-- Updated dependencies [c730fa1dd]
-- Updated dependencies [cd0f6f022]
-  - @tinacms/graphql@0.59.7
-
-## 0.60.5
-
-### Patch Changes
-
-- 399fbf4fa: Fix an issue where builds weren't happening during CI, this is only an issue for the experimental data layer
-
-## 0.60.4
-
-### Patch Changes
-
-- a05546eb4: Added basic open source telemetry
-
-  See [this discussion](https://github.com/tinacms/tinacms/discussions/2451) for more information and how to opt out.
-
-- Updated dependencies [8bf0ac832]
-- Updated dependencies [a05546eb4]
-  - @tinacms/metrics@0.0.2
-  - @tinacms/datalayer@0.0.2
-  - @tinacms/graphql@0.59.6
-
-## 0.60.3
-
-### Patch Changes
-
-- 43b40cc8b: Implement useTina in CLI init
-- b399c734c: Fixes support for collection.templates in graphql
-- Updated dependencies [b399c734c]
-  - @tinacms/datalayer@0.0.2
-  - @tinacms/graphql@0.59.6
-
-## 0.60.2
-
-### Patch Changes
-
-- d17de356a: Update CLI to use apiUrl
-- a67b0c1d7: Dont reinstantiate bridge and store
-
-## 0.60.1
-
-### Patch Changes
-
-- Updated dependencies [8ad8f03fd]
-- Updated dependencies [04b7988d5]
-- Updated dependencies [e3c41f69d]
-- Updated dependencies [f5390e841]
-- Updated dependencies [32082e0b3]
-  - @tinacms/graphql@0.59.5
-  - @tinacms/datalayer@0.0.1
-
-## 0.60.0
-
-### Minor Changes
-
-- 35884152b: Adds and audit command that checks files for errors.
-
-### Patch Changes
-
-- 083aa8ec6: Rebuild database every save while in local mode
-- Updated dependencies [b66aefde1]
-- Updated dependencies [35884152b]
-- Updated dependencies [4948beec6]
-  - @tinacms/graphql@0.59.4
-
-## 0.59.0
-
-### Minor Changes
-
-- 70da62fe8: deprecated the use of `getStaticPropsForTina`
-
-### Patch Changes
-
-- 80732bd97: Create a @tinacms/datalayer package which houses the logic for data management for the GraphQL API. This simplifies the @tinacms/graphql package and allows for a clearer separation.
-- Updated dependencies [34cd3a44a]
-- Updated dependencies [b006a5ab9]
-- Updated dependencies [a324b9c37]
-- Updated dependencies [80732bd97]
-- Updated dependencies [0bec208e2]
-- Updated dependencies [5c070a83f]
-  - @tinacms/graphql@0.59.3
-  - @tinacms/datalayer@0.0.1
-
-## 0.58.5
-
-### Patch Changes
-
-- Updated dependencies [212685fc3]
-  - @tinacms/graphql@0.59.2
-
-## 0.58.4
-
-### Patch Changes
-
-- 118524507: Fixed typo in admin link
-- Updated dependencies [f46c6f987]
-  - @tinacms/graphql@0.59.1
-
-## 0.58.3
-
-### Patch Changes
-
-- Updated dependencies [bd4e1f802]
-- Updated dependencies [62bea7019]
-  - @tinacms/graphql@0.59.0
-
-## 0.58.2
-
-### Patch Changes
-
-- Updated dependencies [fffce3af8]
-  - @tinacms/graphql@0.58.2
-
-## 0.58.1
-
-### Patch Changes
-
-- Updated dependencies [4700d7ae4]
-  - @tinacms/graphql@0.58.1
-
-## 0.58.0
-
-### Minor Changes
-
-- fa7a0419f: Adds experimental support for a data layer between file-based content and the GraphQL API. This allows documents to be indexed so the CMS can behave more like a traditional CMS, with the ability enforce foreign reference constraints and filtering/pagination capabilities.
-- 8c14f29ef: Updated cli to include a new option, `--noSDK`. When this flag is present it will not generate the SDK.
-
-### Patch Changes
-
-- 9c5f888a3: Modifies `tinacms init` for `TinaAdmin`-ready page
-- Updated dependencies [eb5fbfac7]
-- Updated dependencies [fa7a0419f]
-- Updated dependencies [47d126029]
-  - @tinacms/graphql@0.58.0
-
-## 0.57.2
-
-### Patch Changes
-
-- edb2f4011: Trim path property on collections during compilation
-- Updated dependencies [edb2f4011]
-  - @tinacms/graphql@0.57.2
-
-## 0.57.1
-
-### Patch Changes
-
-- 50710e1d0: Add no-check for Typescript-generated file
-- c78d981e6: Reset entire **generated** folder on re-compile
-- Updated dependencies [60729f60c]
-  - @tinacms/graphql@0.57.1
-
-## 0.57.0
-
-### Minor Changes
-
-- d1ed404ba: Add support for auto-generated SDK for type-safe data fetching
-
-### Patch Changes
-
-- 138ceb8c4: Clean up dependencies
-- Updated dependencies [138ceb8c4]
-- Updated dependencies [577d6a5ad]
-- Updated dependencies [ed277e3bd]
-- Updated dependencies [d1ed404ba]
-  - @tinacms/graphql@0.57.0
-
-## 0.56.5
-
-### Patch Changes
-
-- 33ebe7a41: updated cli generated files
-- Updated dependencies [4b7795612]
-  - @tinacms/graphql@0.56.1
-
-## 0.56.4
-
-### Patch Changes
-
-- b99baebf1: Add rich-text editor based on mdx, bump React dependency requirement to 16.14
-- Updated dependencies [891623c7c]
-- Updated dependencies [b99baebf1]
-  - @tinacms/graphql@0.56.0
-
-## 0.56.3
-
-### Patch Changes
-
-- 7c389cb0f: Remove Forestry reference in CLI hint
-
-## 0.56.2
-
-### Patch Changes
-
-- Updated dependencies [9ecb392ca]
-  - @tinacms/graphql@0.55.2
-
-## 0.56.1
-
-### Patch Changes
-
-- Updated dependencies [ff4446c8e]
-- Updated dependencies [667c33e2a]
-  - @tinacms/graphql@0.55.1
-
-## 0.56.0
-
-### Minor Changes
-
-- f3bddeb4a: Added new warning messages for list UI that we do not support by default
-- 455a44359: Add noWatch option to server:start command. When this option is used, the config is not regenerated on file changes.
-
-### Patch Changes
-
-- Updated dependencies [2908f8176]
-- Updated dependencies [5d83643b2]
-- Updated dependencies [f3bddeb4a]
-  - @tinacms/graphql@0.55.0
-
-## 0.55.2
-
-### Patch Changes
-
-- e6e727697: feat: add simpler err message
-- 9b27192fe: Build packages with new scripting, which includes preliminary support for ES modules.
-- Updated dependencies [9b27192fe]
-  - @tinacms/graphql@0.54.3
-
-## 0.55.1
-
-### Patch Changes
-
-- d94fec611: Improve exported types for defineSchema
-- Updated dependencies [d94fec611]
-  - @tinacms/graphql@0.54.2
-
-## 0.55.0
-
-### Minor Changes
-
-- f4f652dae: Updated regex for CSS in tina init CLI
-
-## 0.54.2
-
-### Patch Changes
-
-- Updated dependencies [4de977f63]
-  - @tinacms/graphql@0.54.1
-
-## 0.54.1
-
-### Patch Changes
-
-- Updated dependencies [7663e0f7f]
-  - @tinacms/graphql@0.54.0
-
-## 0.54.0
-
-### Minor Changes
-
-- 069c63b73: Tina init command now adds exit-admin path
-
-### Patch Changes
-
-- Updated dependencies [b4f5e973f]
-  - @tinacms/graphql@0.53.0
-
-## 0.53.3
-
-### Patch Changes
-
-- Updated dependencies [b4bbdda86]
-  - @tinacms/graphql@0.52.2
-
-## 0.53.2
-
-### Patch Changes
-
-- Updated dependencies [b05c91c6]
-  - @tinacms/graphql@0.52.1
-
-## 0.53.1
-
-### Patch Changes
-
-- 7d2307321: Fixed the new line character in the @tinacms/cli init command
-- Updated dependencies [aa4507697]
-  - @tinacms/graphql@0.52.0
-
-## 0.53.0
-
-### Minor Changes
-
-- 35d6f5e7: Added better error handleing for childProcess
-
-## 0.52.2
-
-### Patch Changes
-
-- Updated dependencies [589c7806]
-  - @tinacms/graphql@0.51.1
-
-## 0.52.1
-
-### Patch Changes
-
-- c66b7eef: added regex to add css files to generated file
-- Updated dependencies [5a934f6b]
-- Updated dependencies [271a72d7]
-  - @tinacms/graphql@0.51.0
-
-## 0.52.0
-
-### Minor Changes
-
-- d6dd2886: Added styles to generated files from CLI
-
-### Patch Changes
-
-- 853330c1: Fix issue where NEXT_PUBLIC_EDIT_BRANCH was actually NEXT_PUBLIC_EDIT_BRACH in generated file
-
-## 0.51.1
-
-### Patch Changes
-
-- Updated dependencies [0970961f]
-  - @tinacms/graphql@0.50.2
-
-## 0.51.0
-
-### Minor Changes
-
-- 25e0be67: update generated files in CLI
-
-## 0.50.1
-
-### Patch Changes
-
-- Updated dependencies [65b3e3a3]
-  - @tinacms/graphql@0.50.1
-
-## 0.50.0
-
-### Minor Changes
-
-- 7f3c8c1a: # 🔧 Changes coming to TinaCMS ⚙️
-
-  👋 You may have noticed we've been hard at-work lately building out a more opinionated approach to TinaCMS. To that end, we've settled around a few key points we'd like to announce. To see the work in progress, check out the [main](https://github.com/tinacms/tinacms/tree/main) branch, which will become the primary branch soon.
-
-  ## Consolidating @tinacms packages in to @tinacms/toolkit
-
-  By nature, Tina relies heavily on React context, and the dependency mismatches from over-modularizing our toolkit has led to many bugs related to missing context. To fix this, we'll be consolidating nearly every package in the @tinacms scope to a single package called `@tinacms/toolkit`
-
-  We'll also be rolling out esm support as it's now much easier to address build improvements
-
-  ## A more focused tinacms package
-
-  The `tinacms` package now comes baked-in with APIs for working with the TinaCMS GraphQL API. Because `@tinacms/toolkit` now encompasses everything you'd need to build your own CMS integration, we're repurposing the `tinacms` package to more accurately reflect the "batteries-included" approach.
-
-  If you haven't been introduced, the GraphQL API is a Git-backed CMS which we'll be leaning into more in the future. With a generous free tier and direct syncing with Github its something we're really excited to push forward. Sign up for free here
-  Note: tinacms still exports the same APIs, but we'll gradually start moving the backend-agnostic tools to @tinacms/toolkit.
-
-  ## Consolidating the tina-graphql-gateway repo
-
-  The tina-graphql-gateway repo will be absorbed into this one. If you've been working with our GraphQL APIs you'll need to follow our migration guide.
-
-  ## Moving from Lerna to Yarn PNP
-
-  We've had success with Yarn 2 and PNP in other monorepos, if you're a contributor you'll notice some updates to the DX, which should hopefully result in a smoother experience.
-
-  ## FAQ
-
-  ### What about other backends?
-
-  The `@tinacms/toolkit` isn't going anywhere. And if you're using packages like `react-tinacms-strapi` or r`eact-tinacms-github` with success, that won't change much, they'll just be powered by `@tinacms/toolkit` under the hood.
-
-  ### Do I need to do anything?
-
-  We'll be bumping all packages to `0.50.0` to reflect the changes. If you're using @tincams scoped packages those won't receive the upgrade. Unscoped packages like `react-tinacms-editor` will be upgraded, and should be bumped to 0.50.0 as well.
-  When we move to `1.0.0` we'll be pushing internal APIs to `@tinacms/toolkit`, so that's the long-term location of
-
-  ### Will you continue to patch older versions?
-
-  We'll continue to make security patches, however major bug fixes will likely not see any updates. Keep in mind that `@tinacms/toolkit` will continue to be developed.
-
-### Patch Changes
-
-- Updated dependencies [7f3c8c1a]
-  - @tinacms/graphql@0.1.0
-
-## 0.4.0
-
-### Minor Changes
-
-- 7351d92f: # Define schema changes
-
-  We're going to be leaning on a more _primitive_ concept of how types are defined with Tina, and in doing so will be introducing some breaking changes to the way schemas are defined. Read the detailed [RFC discussion](https://github.com/tinacms/rfcs/pull/18) for more on this topic, specifically the [latter portions](https://github.com/tinacms/rfcs/pull/18#issuecomment-805400313) of the discussion.
-
-  ## Collections now accept a `fields` _or_ `templates` property
-
-  You can now provide `fields` instead of `templates` for your collection, doing so will result in a more straightforward schema definition:
-
-  ```js
-  {
-    collections: [
-      {
-        name: 'post',
-        label: 'Post',
-        path: 'content/posts',
-        fields: [
-          {
-            name: 'title',
-            label: 'Title',
-            type: 'string', // read on below to learn more about _type_ changes
-          },
-        ],
-        // defining `fields` and `templates` would result in a compilation error
-      },
-    ]
-  }
-  ```
-
-  **Why?**
-
-  Previously, a collection could define multiple templates, the ambiguity introduced with this feature meant that your documents needed a `_template` field on them so we'd know which one they belonged to. It also mean having to disambiguate your queries in graphql:
-
-  ```graphql
-  getPostDocument(relativePage: $relativePath) {
-    data {
-      ...on Article_Doc_Data {
-        title
-      }
-    }
-  }
-  ```
-
-  Going forward, if you use `fields` on a collection, you can omit the `_template` key and simplify your query:
-
-  ```graphql
-  getPostDocument(relativePage: $relativePath) {
-    data {
-      title
-    }
-  }
-  ```
-
-  ## `type` changes
-
-  Types will look a little bit different, and are meant to reflect the lowest form of the shape they can represent. Moving forward, the `ui` field will represent the UI portion of what you might expect. For a blog post "description" field, you'd define it like this:
-
-  ```js
-  {
-    type: "string",
-    label: "Description",
-    name: "description",
-  }
-  ```
-
-  By default `string` will use the `text` field, but you can change that by specifying the `component`:
-
-  ```js
-  {
-    type: "string",
-    label: "Description",
-    name: "description",
-    ui: {
-      component: "textarea"
-    }
-  }
-  ```
-
-  For the most part, the UI properties are added to the field and adhere to the existing capabilities of Tina's core [field plugins](https://tina.io/docs/fields/). But there's nothing stopping you from providing your own components -- just be sure to register those with the CMS object on the frontend:
-
-  ```js
-  {
-    type: "string",
-    label: "Description",
-    name: "description",
-    ui: {
-      component: "myMapField"
-      someAdditionalMapConfig: 'some-value'
-    }
-  }
-  ```
-
-  [Register](https://tina.io/docs/fields/custom-fields/#registering-the-plugin) your `myMapField` with Tina:
-
-  ```js
-  cms.fields.add({
-    name: 'myMapField',
-    Component: MapPicker,
-  })
-  ```
-
-  ### One important gotcha
-
-  Every property in the `defineSchema` API must be serlializable. Meaning functions will not work. For example, there's no way to define a `validate` or `parse` function at this level. However, you can either use the [formify](https://tina.io/docs/tina-cloud/client/#formify) API to get access to the Tina form, or provide your own logic by specifying a plugin of your choice:
-
-  ```js
-  {
-    type: "string",
-    label: "Description",
-    name: "description",
-    ui: {
-      component: "myText"
-    }
-  }
-  ```
-
-  And then when you register the plugin, provide your custom logic here:
-
-  ```js
-  import { TextFieldPlugin } from 'tinacms'
-
-  // ...
-
-  cms.fields.add({
-    ...TextFieldPlugin, // spread existing text plugin
-    name: 'myText',
-    validate: value => {
-      someValidationLogic(value)
-    },
-  })
-  ```
-
-  **Why?**
-
-  The reality is that under the hood this has made no difference to the backend, so we're removing it as a point of friction. Instead, `type` is the true definition of the field's _shape_, while `ui` can be used for customizing the look and behavior of the field's UI.
-
-  ## Defensive coding in Tina
-
-  When working with GraphQL, there are 2 reasons a property may not be present.
-
-  1. The data is not a required property. That is to say, if I have a blog post document, and "category" is an optional field, we'll need to make sure we factor that into how we render our page:
-
-  ```tsx
-  const MyPage = props => {
-    return (
-      <>
-        <h2>{props.getPostDocument.data.title}</h2>
-        <MyCategoryComponent>
-          {props.getPostDocument.data?.category}
-        </MyCategoryComponent>
-      </>
-    )
-  }
-  ```
-
-  2. The query did not ask for that field:
-
-  ```graphql
-  {
-    getPostDocument {
-      data {
-        title
-      }
-    }
-  }
-  ```
-
-  But with Tina, there's a 3rd scenario: the document may be in an invalid state. Meaning, we could mark the field as `required` _and_ query for the appropriate field, and _still_ not have the expected shape of data. Due to the contextual nature of Tina, it's very common to be in an intermediate state, where your data is incomplete simply because you're still working on it. Most APIs would throw an error when a document is in an invalid state. Or, more likely, you couldn't even request it.
-
-  ## Undefined list fields will return `null`
-
-  Previously an listable field which wasn't defined in the document was treated as an emptry array. So for example:
-
-  ```md
-  ---
-  title: 'Hello, World'
-  categories:
-    - sports
-    - movies
-  ---
-  ```
-
-  The responsee would be `categories: ['sports', 'movies']`. If you omit the items, but kept the empty array:
-
-  ```md
-  ---
-  title: 'Hello, World'
-  categories: []
-  ---
-  ```
-
-  The responsee would be `categories: []`. If you omit the field entirely:
-
-  ```md
-  ---
-  title: 'Hello, World'
-  ---
-  ```
-
-  The response will be `categories: null`. Previously this would have been `[]`, which was incorrect.
-
-  ## For a listable item which is `required: true` you _must_ provide a `ui.defaultItem` property
-
-  ### Why?
-
-  It's possible for Tina's editing capabilities to introduce an invalid state during edits to list items. Imagine the scenario where you are iterating through an array of objects, and each object has a categories array on it we'd like to render:
-
-  ```tsx
-  const MyPage = props => {
-    return props.blocks.map(block => {
-      return (
-        <>
-          <h2>{block.categories.split(',')}</h2>
-        </>
-      )
-    })
-  }
-  ```
-
-  For a new item, `categories` will be null, so we'll get an error. This only happens when you're editing your page with Tina, so it's not a production-facing issue.
-
-  ## Every `type` can be a list
-
-  Previously, we had a `list` field, which allowed you to supply a `field` property. Instead, _every_ primitive type can be represented as a list:
-
-  ```js
-  {
-    type: "string",
-    label: "Categories",
-    name: "categories",
-    list: true
-  }
-  ```
-
-  Additionally, enumerable lists and selects are inferred from the `options` property. The following example is represented by a `select` field:
-
-  ```js
-  {
-    type: "string",
-    label: "Categories",
-    name: "categories",
-    options: ["fitness", "movies", "music"]
-  }
-  ```
-
-  While this, is a `checkbox` field
-
-  ```js
-  {
-    type: "string",
-    label: "Categories",
-    name: "categories"
-    list: true,
-    options: ["fitness", "movies", "music"]
-  }
-  ```
-
-  > Note we may introduce an `enum` type, but haven't discussed it thoroughly
-
-  ## Introducing the `object` type
-
-  Tina currently represents the concept of an _object_ in two ways: a `group` (and `group-list`), which is a uniform collection of fields; and `blocks`, which is a polymporphic collection. Moving forward, we'll be introducing a more comporehensive type, which envelopes the behavior of both `group` and `blocks`, and since _every_ field can be a `list`, this also makes `group-list` redundant.
-
-  > Note: we've previously assumed that `blocks` usage would _always_ be as an array. We'll be keeping that assumption with the `blocks` type for compatibility, but `object` will allow for non-array polymorphic objects.
-
-  ### Defining an `object` type
-
-  An `object` type takes either a `fields` _or_ `templates` property (just like the `collections` definition). If you supply `fields`, you'll end up with what is essentially a `group` item. And if you say `list: true`, you'll have what used to be a `group-list` definition.
-
-  Likewise, if you supply a `templates` field and `list: true`, you'll get the same API as `blocks`. However you can also say `list: false` (or omit it entirely), and you'll have a polymorphic object which is _not_ an array.
-
-  This is identical to the current `blocks` definition:
-
-  ```js
-  {
-    type: "object",
-    label: "Page Sections",
-    name: "pageSections",
-    list: true,
-    templates: [{
-      label: "Hero",
-      name: "hero",
-      fields: [{
-        label: "Title",
-        name: "title",
-        type: "string"
-      }]
-    }]
-  }
-  ```
-
-  And here is one for `group`:
-
-  ```js
-  {
-    type: "object",
-    label: "Hero",
-    name: "hero",
-    fields: [{
-      label: "Title",
-      name: "title",
-      type: "string"
-    }]
-  }
-  ```
-
-  ## `dataJSON` field
-
-  You can now request `dataJSON` for the entire data object as a single query key. This is great for more tedius queries like theme files where including each item in the result is cumbersome.
-
-  > Note there is no typescript help for this feature for now
-
-  ```graphql
-  getThemeDocument(relativePath: $relativePath) {
-    dataJSON
-  }
-  ```
-
-  ```json
-  {
-    "getThemeDocument": {
-      "dataJSON": {
-        "every": "field",
-        "in": {
-          "the": "document"
-        },
-        "is": "returned"
-      }
-    }
-  }
-  ```
-
-  ## Lists queries will now adhere to the GraphQL connection spec
-
-  [Read the spec](https://relay.dev/graphql/connections.htm)
-
-  Previously, lists would return a simple array of items:
-
-  ```graphql
-  {
-    getPostsList {
-      id
-    }
-  }
-  ```
-
-  Which would result in:
-
-  ```json
-  {
-    "data": {
-      "getPostsList": [
-        {
-          "id": "content/posts/voteForPedro.md"
-        }
-      ]
-    }
-  }
-  ```
-
-  In the new API, you'll need to step through `edges` & `nodes`:
-
-  ```graphql
-  {
-    getPostsList {
-      edges {
-        node {
-          id
-        }
-      }
-    }
-  }
-  ```
-
-  ```json
-  {
-    "data": {
-      "getPostsList": {
-        "edges": [
-          {
-            "node": {
-              "id": "content/posts/voteForPedro.md"
-            }
-          }
-        ]
-      }
-    }
-  }
-  ```
-
-  **Why?**
-
-  The GraphQL connection spec opens up a more future-proof structure, allowing us to put more information in to the _connection_ itself like how many results have been returned, and how to request the next page of data.
-
-  Read [a detailed explanation](https://graphql.org/learn/pagination/) of how the connection spec provides a richer set of capabilities.
-
-  > Note: sorting and filtering is still not supported for list queries.
-
-  ## `_body` is no longer included by default
-
-  There is instead an `isBody` boolean which can be added to any `string` field
-
-  **Why?**
-
-  Since markdown files sort of have an implicit "body" to them, we were automatically populating a field which represented the body of your markdown file. This wasn't that useful, and kind of annoying. Instead, just attach `isBody` to the field which you want to represent your markdown "body":
-
-  ```js
-  {
-    collections: [{
-      name: "post",
-      label: "Post",
-      path: "content/posts",
-      fields: [
-        {
-          name: "title",
-          label: "Title",
-          type: "string"
-        }
-        {
-          name: "myBody",
-          label: "My Body",
-          type: "string",
-          component: 'textarea',
-          isBody: true
-        }
-      ]
-    }]
-  }
-  ```
-
-  This would result in a form field called `My Body` getting saved to the body of your markdown file (if you're using markdown):
-
-  ```md
-  ---
-  title: Hello, World!
-  ---
-
-  This is the body of the file, it's edited through the "My Body" field in your form.
-  ```
-
-  ## References now point to more than one collection.
-
-  Instead of a `collection` property, you must now define a `collections` field, which is an array:
-
-  ```js
-  {
-    type: "reference",
-    label: "Author",
-    name: "author",
-    collections: ["author"]
-  }
-  ```
-
-  ```graphql
-  {
-    getPostDocument(relativePath: "hello.md") {
-      data {
-        title
-        author {
-          ...on Author_Document {
-            name
-          }
-          ...on Post_Document {
-            title
-          }
-        }
-      }
-    }
-  ```
-
-  ## Other breaking changes
-
-  ### The `template` field on polymorphic objects (formerly _blocks_) is now `_template`
-
-  **Old API:**
-
-  ```md
-  ---
-  ---
-  myBlocks:
-    - template: hero
-      title: Hello
-  ---
-  ```
-
-  **New API:**
-
-  ```md
-  ---
-  ---
-  myBlocks:
-    - \_template: hero
-      title: Hello
-  ---
-  ```
-
-  ### `data` `__typename` values have changed
-
-  They now include the proper namespace to prevent naming collisions and no longer require `_Doc_Data` suffix. All generated `__typename` properties are going to be slightly different. We weren't fully namespacing fields so it wasn't possible to guarantee that no collisions would occur. The pain felt here will likely be most seen when querying and filtering through blocks. This ensures the stability of this type in the future
-
-  ```graphql
-  {
-    getPageDocument(relativePath: "home.md") {
-      data {
-        title
-        myBlocks {
-          ...on Page_Hero_Data {  # previously this would have been Hero_Data
-            # ...
-          }
-        }
-      }
-    }
-  ```
-
-- 33e27538: Init command now adds admin.tsx file to the users pages folder
-- 8c8fc2ad: Init script now checks for file extention.
-
-### Patch Changes
-
-- 5cd5ce76: - Improve types for ui field
-  - Marks system fields as required so the user has a guarantee that they'll be there
-  - Return null for listable fields which are null or undefined
-  - Handle null values for reference fields better
-- Updated dependencies [fdb7724b]
-- Updated dependencies [d42e2bcf]
-- Updated dependencies [5cd5ce76]
-- Updated dependencies [8c425440]
-- Updated dependencies [7351d92f]
-  - tina-graphql@0.2.0
-  - tina-graphql-helpers@0.1.2
-
-## 0.3.1
-
-### Patch Changes
-
-- ebe77b21: added iframe to tina init generate page
-
-## 0.3.0
-
-### Minor Changes
-
-- fa3967b3: tina-gql init command now updates the users package.json with tina-dev scripts and adds a \_app.js files into the users project
-
-## 0.2.60
-
-### Patch Changes
-
-- c21bda17: Allow single command arguments to be passed in the sub command for the server:start command
-- Updated dependencies [348ef1e5]
-  - tina-graphql@0.1.25
-
-## 0.2.58
-
-### Patch Changes
-
-- Updated dependencies [b36de960]
-  - tina-graphql@0.1.24
-
-## 0.2.57
-
-### Patch Changes
-
-- Bump packages to reflect new changest capabilities
-- Updated dependencies [undefined]
-  - tina-graphql@0.1.23
-  - tina-graphql-helpers@0.1.1
-
-## 0.2.56
-
-### Patch Changes
-
-- Updated dependencies [undefined]
-  - tina-graphql-helpers@0.1.0
-  - tina-graphql@0.1.22
-
-## 0.2.55
-
-### Patch Changes
-
-- Updated dependencies [undefined]
-  - tina-graphql@0.1.21