Summary

I've been busy with getting a Gatsby site into production and I observed that the app bundle size became unusually large (1.7MB uncompressed), so I installed webpack bundle analyzer and generated a report. And it turned out, that TinaCMS is the main culprit, accounting for around 800-900KB of the size, including dependencies, which are irrelevant to the production build (but are needed for the development server with Tina of course).

I take guidance from the excellent articles The Cost of JavaScript 2018 and The Cost of JavaScript 2019. The overhead that stems from TinaCMS is almost as large as the median uncompressed bundle size. This is a huge obstacle for using Tina with production sites.

Basic example

TinaCMS + its dependencies should not be present in production build. I have no idea though how this can be achieved, since Tina is integrated with code of the site. First thing that comes to mind is Webpack hacking. Maybe you already know that this is a problem and already have an idea how to fix this? If so, this should be part of the docs, since out-of-the-box this blow-up happens.

Here is the report of bundle analyzer of my production build

And this is a regex to filter for dependencies, that are exclusively needed by Tina (@tinacms|prosemirror|codemirror|react-datetime|react-beautiful-dnd|markdown-it|final-form|styled-components|react-dropzone|react-color|tinycolor2|stylis).*.js

Motivation

Obviously faster page loads and less production traffic. Tina should not be that expensive.

Summary

tinacms should provide a number plugin by default.

The base input would be added to @tinacms/fields.

The plugin will be define din tinacms

Basic example

{
   name: "temp",
   label: "Temp",
   component: "number",
   description: "The temperature in Celsius",
}

• [x] add inlineComponent typedef
• [x] fix type errors
• [x] refine FieldTarget styles
• [x] update react-tinacms-inline package docs
• [x] recalculate FieldOverlay position on resize

Copied from original PR by @jsjoeio

This is an active WIP. @ncphillips helped me a little bit but we figured it might be better to start with a draft PR to get some help asynchronously. (I've been too busy with a new job to coordinate outside work. I think this might be easiest.)

Summary

The goal of this PR is to add a new package called gatsby-tinacms-mdx to the tinaCMS/Gatsby package family so that users can use tinaCMS with their Gatsby/MDX sites similar to how they can use it with Markdown.

I struggled to get my local dev env working well to develop this plugin so I ended up developing it in isolation here.

Approach

I essentially copied the exact same approach in gatsby-tinacms-remark but for mdx specifically. That seemed to work for the most part but this isn't 100% complete and is not a fully-functioning state.

What I Need Help With

• Guidance on testing this locally in the monorepo and in a Gatsby demo site (I haven't had much luck following the instructions in the README/CONTRIBUTING hence why I broke it into a separate repo)
• Feedback on what might be missing to get this fully-functioning
• Any other support that can help us get this ready for the community

Many thanks in advance ❤️

Unresolved reviews from original PR

• [x] Lets remove the the .d.ts files and add them to the .gitignore
• [x] Nolan's notes on naming mdxinstead of _mdx

Nolan: The whole component would look like this:

interface MdxFormProps extends Partial<FormOptions<any>> {
  mdx: MdxNode
  render(renderProps: { form: Form; mdx: any }): JSX.Element
  timeout?: number
}

export function MdxForm({ mdx: _mdx, render, ...options }: MdxFormProps) {
  const [mdx, form] = useLocalMdx(_mdx, options)

  return render({ form: form as Form, mdx })
}

The mdx: _mdx lets you pass it in as mdx and then use it as _mdx

• [x] Note for @ncphillips - maybe DeleteAction should be part of the gatsby-tinacms-git plugin. This action could work for Json, Markdown, Mdx, anything stored in git.
• [x] tinacms needs to be a peerDep
• [x] @paulbunker noted: I was having trouble getting this branch to build untill I added "@tinacms/form-builder": "0.2.13" as a dependency

Hey.

This may seem a little much for this functionality. But check it out. I think it's necessary as the structure on things are now. It isn't possible to just set the positioning to "sticky"

Thomas

lerna notice cli v3.16.4
lerna info versioning independent
lerna info filter [ '@tinacms/tinacms' ]
lerna info Executing command in 1 package: "npm run build"
lerna ERR! npm run build exited 1 in '@tinacms/tinacms'
lerna ERR! npm run build stdout:

> @tinacms/[email protected] build /Users/ncphillips/Code/tinacms/tinacms/packages/tinacms
> cms-scripts build

Building Package: @tinacms/[email protected]

lerna ERR! npm run build stderr:
/Users/ncphillips/Code/tinacms/tinacms/packages/@tinacms/scripts/bin/cms-scripts.js:33
  throw err
  ^

Error: /Users/ncphillips/Code/tinacms/tinacms/packages/tinacms/src/components/modals/ModalProvider.tsx(113,14): semantic error TS2742: The inferred type of 'ModalHeader' cannot be named without a reference to '@tinacms/fields/node_modules/@tinacms/styles'. This is likely not portable. A type annotation is necessary.
    at error (/Users/ncphillips/Code/tinacms/tinacms/node_modules/rollup/dist/rollup.js:10151:30)
    at throwPluginError (/Users/ncphillips/Code/tinacms/tinacms/node_modules/rollup/dist/rollup.js:16454:12)
    at Object.error (/Users/ncphillips/Code/tinacms/tinacms/node_modules/rollup/dist/rollup.js:16509:24)
    at Object.error (/Users/ncphillips/Code/tinacms/tinacms/node_modules/rollup/dist/rollup.js:16901:38)
    at RollupContext.error (/Users/ncphillips/Code/tinacms/tinacms/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:17192:30)
    at lodash_3 (/Users/ncphillips/Code/tinacms/tinacms/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:24953:23)
    at arrayEach (/Users/ncphillips/Code/tinacms/tinacms/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:532:11)
    at forEach (/Users/ncphillips/Code/tinacms/tinacms/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:9358:14)
    at printDiagnostics (/Users/ncphillips/Code/tinacms/tinacms/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:24926:5)
    at cache.getCompiled (/Users/ncphillips/Code/tinacms/tinacms/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:26820:21)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @tinacms/[email protected] build: `cms-scripts build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @tinacms/[email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/ncphillips/.npm/_logs/2019-10-09T19_02_43_357Z-debug.log

Related Issue:

• https://github.com/Microsoft/TypeScript/issues/30858

Putting this in a bunch of files fixes the issue:

Which makes no sense because that file doesn't reference @tinacms/fields

Right now every commit is paired with a push. This is required for production use, but it is not always wanted when editing files locally. The developer should be able to configure the git-api, or the git-client, to decide when to push.

getStaticPropsForTina to me feels a bit unnecessary. Its role seems to be to make a request to the local API, as well as returning some of the arguments that were passed in.

Our current starter code:

export const getStaticProps = async ({ params }) => {
  const tinaProps = (await getStaticPropsForTina({
    query: `#graphql
      query BlogPostQuery($relativePath: String!) {
          // ...
      }
    `,
    variables: { relativePath: `${params.filename}.md` },
  })) as { data: { getPostsDocument: PostsDocument } };

  return {
    props: {
      ...tinaProps,
    },
  };
};

This to me feels a bit more clear about what getStaticProps is actually doing/returning:

export const getStaticProps = async ({ params }) => {

  const postRequestArgs = {
    query: `#graphql
      query BlogPostQuery($relativePath: String!) {
         // ...
      }
    `,
    variables: { relativePath: `${params.filename}.md` }
  }

  const post = new LocalClient().request(postRequestArgs)

  return {
    props: {
      post, // use this on your production page
      tinaArgs: postRequestArgs // needed for the Tina wrapper to re-request draft content client-side
    },
  };
})

The proposed solution also wraps all the tina stuff that gets sent to the frontend in a "tinaArgs" object, so it's clear what's for the production site, and what's for the frontend TinaCMScomponent.

Thoughts?

Summary

The WYSIWYG editor should have a button in its toolbar to toggle between editing the raw content and editing in WYSIWYM mode

Motivation

There are still some kinks with the WYSIWYG, and we should track them down and fix them, but in the meantime having a raw mode will allow editors to fix formatting gone awry from the CMS instead of having to open a text editor.

Hey. Here's a working version of the resize function that we discussed. Haven't gone through the code in detail so probably can use some optimization. Added a min width now also. Think it would also be a good idea to have an option to turn resizing on and off when setting up the sidebar.

A few statements about default behavior that we may want to pin down so we know how we'd like to proceed as the extending Tina work progresses.

When in edit-mode, null values are replaced with their default items*

*not working yet, but will - would like to get an idea for expectations before implementing.

This is currently considered a feature, but I'm not sure it's what we want. As an editor, you may land on a page and see exactly what you want (because the developer set up good default values. So you don't save anything or really do anything, and you never exit edit-mode. At that point, when your work goes to production there will be a missing value.

Outermost defaultValue wins

defineSchema({
  collections: [
    {
      label: 'Block Page',
      name: 'blockPage',
      format: 'mdx',
      path: 'content/block-pages',
      fields: [
        {
          label: 'Blocks',
          name: 'blocks',
          type: 'object',
          list: true,
          ui: {
            defaultValue: [{
              _template: 'hero',
              title: "hello #1"
            }]
          },
          templates: [
            {
              name: 'hero',
              label: 'Hero',
              ui: {
                defaultValue: {
                  title: 'hello #2',
                },
              },
              fields: [
                {
                  label: 'Title',
                  name: 'title',
                  type: 'string',
                },
                {
                  label: 'Description',
                  name: 'description',
                  type: 'string',
                },
              ],
            },
          ],
        },
      ],
    },
  ],
})

The value will be:

[{
  _template: 'hero',
  title: "hello #1"
}]

Instead of

[{
  _template: 'hero',
  title: "hello #2"
}]

What should the behavior be is open for interpretation, though some have mentioned this feels wrong and the most-specific property should win.

Similarly, defaultItem on a list object ignores child default values

What is the expected behavior here?

defaultValue is not used if an adjacent field is present

AKA - we don't merge real/default values.

If I have a title field and a description field.

{
  label: 'Title',
  name: 'title',
  type: 'string',
  ui: {
    defaultValue: 'Some title',
  },
},
{
  label: 'Description',
  name: 'description',
  type: 'string',
  ui: {
    defaultValue: 'Some description',
  },
},

And a document with only the title:

---
title: "Hello, World"
---

The form.values will be {title: "Hello, World"}

To make the editing experience more seamless, keybindings for saving the form were added. Now, Command+s or Control+s will trigger a submit on the form, just clicking the save button. Each action follows the states of the save button; if it's disabled/busy/etc., the key bindings will no-op.

Describe the issue that you're seeing. Any Loom videos or screenshots usually help a lot!

The Tina Markdown editor is not able to parse this:

Paragraph

> Quoted paragraph
>
> * Quoted list
> * Quoted list
>
> > Nested quoted paragraph

Paragraph

The above is valid Markdown (by every standard I'm aware of). There may be other elements that don't work inside blockquotes, but those were the only two I encountered so far.

This bug may be related to #3118, although this specific issue is a bigger problem for my content.

Reproduction

https://github.com/johnridesabike/tina-bug-report

Steps to reproduce

1. Add a markdown page with the above content. (Or view content/page/quotedlists.mdx in the example repo)
2. Try to edit it in the Tina editor.
3. The editor will fail to work due to this error:

Error parsing markdown
  
UnwrapBlock: Unknown block content of type list

System Info

System:
    OS: macOS 13.1
    CPU: (6) x64 Intel(R) Core(TM) i5-8500B CPU @ 3.00GHz
    Memory: 93.80 MB / 8.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 19.3.0 - /usr/local/bin/node
    Yarn: 1.22.19 - ~/code/tina-bug-report/my-tina-app/node_modules/.bin/yarn
    npm: 9.2.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Firefox: 108.0.1
    Safari: 16.2
  npmPackages:
    @tinacms/cli: ^1.0.0 => 1.0.0
    tinacms: ^1.0.0 => 1.0.0

Validations

• [X] Follow our Code of Conduct
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug.

Describe the issue that you're seeing. Any Loom videos or screenshots usually help a lot!

The markdown editor seems to expect HTML tags to use XML-style closing tags, even when they aren't necessary. I encountered this after copy/pasting Twitter embed HTML code, which uses <br> (instead of <br />).

Personally, I wonder if the HTML parsing is even necessary. AFAIK, Markdown parsers all just scan for the beginning and end of an HTML block and then output its content as-is. Validation may be a useful optional feature in the editor, but I don't think the editor should completely stop working when it finds an error.

Reproduction

https://github.com/johnridesabike/tina-bug-report

Steps to reproduce

1. Open a markdown file (format: "md").
2. Switch to markdown plain-text mode.
3. Paste some HTML.
4. The editor raises an error message similar to: 1:324-1:328: Unexpected closing tag `</p>`, expected corresponding closing tag for `<br>` (1:158-1:162) at line: 1, column: 324

Here's the example HTML I used:

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">We have no lack of space.<br>Just a lack of imagination!<br><br>&#39;Every street can be a park&#39;<br>~<a href="https://twitter.com/zeeger?ref_src=twsrc%5Etfw">@zeeger</a> (about Plantage Middenlaan) <a href="https://t.co/830QCIka0X">pic.twitter.com/830QCIka0X</a></p>&mdash; Cycling Professor 🚲 (@fietsprofessor) <a href="https://twitter.com/fietsprofessor/status/1399698366288760835?ref_src=twsrc%5Etfw">June 1, 2021</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

System Info

System:
    OS: macOS 13.1
    CPU: (6) x64 Intel(R) Core(TM) i5-8500B CPU @ 3.00GHz
    Memory: 133.57 MB / 8.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 19.3.0 - /usr/local/bin/node
    Yarn: 1.22.19 - ~/code/tina-bug-report/my-tina-app/node_modules/.bin/yarn
    npm: 9.2.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Firefox: 108.0.1
    Safari: 16.2
  npmPackages:
    @tinacms/cli: ^1.0.0 => 1.0.0
    tinacms: ^1.0.0 => 1.0.0

Validations

• [X] Follow our Code of Conduct
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug.

Describe the issue that you're seeing. Any Loom videos or screenshots usually help a lot!

checkGitignoreForNodeModules is not properly accounting for scenarios in which the node_modules gitignore entry is prefixed and/or suffixed with a forward slash.

Reproduction

https://github.com/namoscato/todaypgh

Steps to reproduce

1. given an existing repository with .gitignore, i.e.

   /node_modules/
   

2. run npx @tinacms/cli@latest init

3. see that node_modules entry is incorrectly added

System Info

System:
    OS: macOS 13.1
    CPU: (8) arm64 Apple M1 Pro
    Memory: 159.88 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 16.17.0 - ~/.nvm/versions/node/v16.17.0/bin/node
    Yarn: 1.22.19 - ~/dev/git/todaypgh/node_modules/.bin/yarn
    npm: 8.15.0 - ~/.nvm/versions/node/v16.17.0/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Chrome Canary: 111.0.5508.0
    Firefox: 104.0.2
    Safari: 16.2
  npmPackages:
    @tinacms/cli: ^1.0.5 => 1.0.5 
    tinacms: ^1.1.2 => 1.1.2

Validations

• [X] Follow our Code of Conduct
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug.

Describe the issue that you're seeing. Any Loom videos or screenshots usually help a lot!

I started a Discord thread but haven't heard back, so I'm opening this issue.

After running the init CLI command, I'm unable to start the dev server, presumably due to conflicting graphql package versions across @tinacms/cli, tinacms, and their indirect dependencies:

$ npm run dev

> [email protected] dev
> tinacms dev -c "hugo server -D"

 TinaCMS  - Build Started

Compilation failed with errors. Server has not been restarted. see error below 
 Cannot use GraphQLScalarType "Reference" from another module or realm.

[email protected] /Users/nick/dev/git/todaypgh
├─┬ @tinacms/[email protected]
│ ├─┬ @graphql-codegen/[email protected]
│ │ ├─┬ @graphql-tools/[email protected]
│ │ │ ├─┬ @graphql-tools/[email protected]
│ │ │ │ └── [email protected] deduped
│ │ │ └── [email protected] deduped
│ │ ├─┬ @graphql-tools/[email protected]
│ │ │ └── [email protected] deduped
│ │ └── [email protected]
│ ├─┬ @graphql-codegen/[email protected]
│ │ └── [email protected] deduped
│ ├─┬ @graphql-codegen/[email protected]
│ │ ├─┬ @graphql-codegen/[email protected]
│ │ │ ├─┬ @graphql-tools/[email protected]
│ │ │ │ └── [email protected] deduped
│ │ │ └── [email protected] deduped
│ │ ├─┬ @graphql-codegen/[email protected]
│ │ │ └── [email protected] deduped
│ │ └── [email protected] deduped
│ ├─┬ @graphql-codegen/[email protected]
│ │ └── [email protected] deduped
│ ├─┬ @graphql-codegen/[email protected]
│ │ ├─┬ @graphql-codegen/[email protected]
│ │ │ └── [email protected] deduped
│ │ └── [email protected] deduped
│ ├─┬ @graphql-codegen/[email protected]
│ │ ├─┬ @graphql-tools/[email protected]
│ │ │ └── [email protected] deduped
│ │ └── [email protected] deduped
│ ├─┬ @graphql-tools/[email protected]
│ │ ├─┬ @graphql-tools/[email protected]
│ │ │ └── [email protected] deduped
│ │ └── [email protected] deduped
│ ├─┬ @graphql-tools/[email protected]
│ │ └── [email protected] deduped
│ ├─┬ @tinacms/[email protected]
│ │ └── [email protected]
│ ├─┬ @tinacms/[email protected]
│ │ └── [email protected]
│ ├─┬ @tinacms/[email protected]
│ │ ├─┬ [email protected]
│ │ │ └── [email protected] deduped
│ │ └── [email protected]
│ └── [email protected]
├─┬ [email protected]
│ └─┬ [email protected]
│   └── [email protected] deduped
└─┬ [email protected]
  ├─┬ @graphql-tools/[email protected]
  │ ├─┬ @ardatan/[email protected]
  │ │ └── [email protected] deduped
  │ └── [email protected] deduped
  ├─┬ [email protected]
  │ └── [email protected] deduped
  └── [email protected]

Reproduction

https://github.com/namoscato/todaypgh/pull/123

Steps to reproduce

1. checkout https://github.com/namoscato/todaypgh/pull/123
2. use Node.js v16: nvm use
3. install dependencies: npm i
4. npm run dev

System Info

System:
    OS: macOS 13.1
    CPU: (8) arm64 Apple M1 Pro
    Memory: 159.88 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 16.17.0 - ~/.nvm/versions/node/v16.17.0/bin/node
    Yarn: 1.22.19 - ~/dev/git/todaypgh/node_modules/.bin/yarn
    npm: 8.15.0 - ~/.nvm/versions/node/v16.17.0/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Chrome Canary: 111.0.5508.0
    Firefox: 104.0.2
    Safari: 16.2
  npmPackages:
    @tinacms/cli: ^1.0.5 => 1.0.5 
    tinacms: ^1.1.2 => 1.1.2

Validations

• [X] Follow our Code of Conduct
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug.

Describe the issue that you're seeing. Any Loom videos or screenshots usually help a lot!

PRs to the main branch fail with the following error:

Error when checking client information. You provided
--
08:35:22.787 |  
08:35:22.787 | {
08:35:22.787 | "branch": "dependabot/npm_and_yarn/typeit-8.7.1",
08:35:22.787 | "clientId": "<clientid>",
08:35:22.787 | "token": "<token>"
08:35:22.787 | }
08:35:22.787 |  
08:35:22.787 | Please check you have the correct "clientId", "branch" and "token" configured. For more information see https://tina.io/docs/tina-cloud/connecting-site/
08:35:22.787 | Error: Server responded with status code 404, Not Found.
08:35:22.787 |  
08:35:22.787 | Message from server: Unable to find record '.tina/__generated__/_graphql.json' in Github Repository: 'mAAdhaTTah/frontend[/]', Ref: 'master' [NOTE: The specified branch, 'dependabot/npm_and_yarn/typeit-8.7.1', has not been indexed by Tina Cloud. See https://tina.io/docs/tina-cloud/faq/#how-do-i-resolve-errors-caused-by-unindexed-branches] Please see our FAQ for more information: https://tina.io/docs/errors/faq/
08:35:22.788 | Error: Server responded with status code 404, Not Found.
08:35:22.788 |  
08:35:22.788 | Message from server: Unable to find record '.tina/__generated__/_graphql.json' in Github Repository: 'mAAdhaTTah/frontend[/]', Ref: 'master' [NOTE: The specified branch, 'dependabot/npm_and_yarn/typeit-8.7.1', has not been indexed by Tina Cloud. See https://tina.io/docs/tina-cloud/faq/#how-do-i-resolve-errors-caused-by-unindexed-branches] Please see our FAQ for more information: https://tina.io/docs/errors/faq/
08:35:22.788 | at request (/vercel/path0/node_modules/@tinacms/cli/dist/index.js:2781:11)
08:35:22.788 | at processTicksAndRejections (node:internal/process/task_queues:96:5)
08:35:22.788 | at async Array.checkClientInfo (/vercel/path0/node_modules/@tinacms/cli/dist/index.js:2801:5)
08:35:22.788 | at async next (/vercel/path0/node_modules/@tinacms/cli/dist/index.js:535:7)
08:35:22.907 | Error: Command "npm run build" exited with 1

Deployments on main work correctly. Note that I recently renamed master -> main, in case that has something to do with it. I did reset the repository cache, to no avail.

Reproduction

https://github.com/mAAdhaTTah/frontend/pull/771

Steps to reproduce

No response

System Info

System:
    OS: macOS High Sierra 10.13.6
    CPU: (4) x64 Intel(R) Core(TM) i5-4690K CPU @ 3.50GHz
    Memory: 2.31 GB / 32.00 GB
    Shell: 5.1.16 - /usr/local/bin/bash
  Binaries:
    Node: 17.6.0 - /usr/local/bin/node
    Yarn: 1.22.19 - ~/Code/Infra/domain/frontend/node_modules/.bin/yarn
    npm: 8.5.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Firefox: 99.0.1
    Firefox Developer Edition: 77.0
    Safari: 13.1.2
  npmPackages:
    @tinacms/cli: ^1.0.4 => 1.0.4
    @tinacms/mdx: ^1.0.3 => 1.0.3
    tinacms: ^1.1.1 => 1.1.1

Validations

• [X] Follow our Code of Conduct
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug.