taxonomy Documentation

File: README.md Copy Chapter

[!NOTE]
This project has been officially archived and will no longer receive updates. See the Templates directory for Next.js starters.

I started this project when the Next.js App Router was in public preview. Because the framework has since stabilized and undergone significant architectural changes, the code in this repository:

• Does not reflect current best practices.
• May contain deprecated APIs or patterns.
• Is not recommended for use in production environments.

Taxonomy

An open source application built using the new router, server components and everything new in Next.js 13.

About this project Copy Chapter

This project as an experiment to see how a modern app (with features like authentication, subscriptions, API routes, static pages for docs ...etc) would work in Next.js 13 and server components.

Features Copy Chapter

• New /app dir,
• Routing, Layouts, Nested Layouts and Layout Groups
• Data Fetching, Caching and Mutation
• Loading UI
• Route handlers
• Metadata files
• Server and Client Components
• API Routes and Middlewares
• Authentication using NextAuth.js
• ORM using Prisma
• Database on PlanetScale
• UI Components built using Radix UI
• Documentation and blog using MDX and Contentlayer
• Subscriptions using Stripe
• Styled using Tailwind CSS
• Validations using Zod
• Written in TypeScript

Roadmap Copy Chapter

• Add MDX support for basic pages
• Build marketing pages
• Subscriptions using Stripe
• Responsive styles
• Add OG image for blog using @vercel/og
• Dark mode

Known Issues Copy Chapter

A list of things not working right now:

1. GitHub authentication (use email)
2. Prisma: Error: ENOENT: no such file or directory, open '/var/task/.next/server/chunks/schema.prisma'
3. Next.js 13: Client side navigation does not update head
4. Cannot use opengraph-image.tsx inside catch-all routes

Why not tRPC, Turborepo or X? Copy Chapter

I might add this later. For now, I want to see how far we can get using Next.js only.

If you have some suggestions, feel free to create an issue.

Running Locally Copy Chapter

1. Install dependencies using pnpm:

pnpm install

2. Copy .env.example to .env.local and update the variables.

cp .env.example .env.local

3. Start the development server:

pnpm dev

License Copy Chapter

Licensed under the MIT license.

File: content/pages/privacy.mdx Copy Chapter

title: Privacy Copy Chapter

Blandit libero volutpat sed cras ornare arcu. Cursus sit amet dictum sit amet. Nunc vel risus commodo viverra maecenas accumsan. Libero id faucibus nisl tincidunt eget nullam non nisi est. Varius quam quisque id diam vel quam. Id donec ultrices tincidunt arcu non.

Consent Copy Chapter

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Volutpat sed cras ornare arcu. Nibh ipsum consequat nisl vel pretium lectus quam id leo. A arcu cursus vitae congue. Amet justo donec enim diam. Vel pharetra vel turpis nunc eget lorem. Gravida quis blandit turpis cursus in. Semper auctor neque vitae tempus. Elementum facilisis leo vel fringilla est ullamcorper eget nulla. Imperdiet nulla malesuada pellentesque elit eget.

Felis donec et odio pellentesque diam volutpat commodo sed.

Tortor consequat id porta nibh. Fames ac turpis egestas maecenas pharetra convallis posuere morbi leo. Scelerisque fermentum dui faucibus in. Tortor posuere ac ut consequat semper viverra.

Information we collect Copy Chapter

Amet justo donec enim diam. In hendrerit gravida rutrum quisque non. Hac habitasse platea dictumst quisque sagittis purus sit.

How we use your Information Copy Chapter

Ut sem nulla pharetra diam sit amet nisl suscipit adipiscing. Consectetur adipiscing elit pellentesque habitant. Ut tristique et egestas quis ipsum suspendisse ultrices gravida.

File: content/pages/terms.mdx Copy Chapter

title: Terms & Conditions Copy Chapter

Lorem ipsumMagna fermentum iaculis eu non diam. Vitae purus faucibus ornare suspendisse sed nisi lacus sed. In nibh mauris cursus mattis molestie a iaculis at. Enim sit amet venenatis urna. Eget sit amet tellus cras adipiscing.

Legal Notices Copy Chapter

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Volutpat sed cras ornare arcu. Nibh ipsum consequat nisl vel pretium lectus quam id leo. A arcu cursus vitae congue. Amet justo donec enim diam. Vel pharetra vel turpis nunc eget lorem. Gravida quis blandit turpis cursus in. Semper auctor neque vitae tempus. Elementum facilisis leo vel fringilla est ullamcorper eget nulla. Imperdiet nulla malesuada pellentesque elit eget.

Felis donec et odio pellentesque diam volutpat commodo sed.

Tortor consequat id porta nibh. Fames ac turpis egestas maecenas pharetra convallis posuere morbi leo. Scelerisque fermentum dui faucibus in. Tortor posuere ac ut consequat semper viverra.

Warranty Disclaimer Copy Chapter

Tellus in hac habitasse platea dictumst vestibulum. Faucibus in ornare quam viverra. Viverra aliquet eget sit amet tellus cras adipiscing. Erat nam at lectus urna duis convallis convallis tellus. Bibendum est ultricies integer quis auctor elit sed vulputate.

Nisl condimentum id venenatis a condimentum vitae. Ac auctor augue mauris augue neque gravida in fermentum. Arcu felis bibendum ut tristique. Tempor commodo ullamcorper a lacus vestibulum sed arcu non.

General Copy Chapter

Magna fermentum iaculis eu non diam. Vitae purus faucibus ornare suspendisse sed nisi lacus sed. In nibh mauris cursus mattis molestie a iaculis at. Enim sit amet venenatis urna. Eget sit amet tellus cras adipiscing.

Sed lectus vestibulum mattis ullamcorper velit. Id diam vel quam elementum pulvinar. In iaculis nunc sed augue lacus viverra. In hendrerit gravida rutrum quisque non tellus. Nisl purus in mollis nunc.

Disclaimer Copy Chapter

Amet justo donec enim diam. In hendrerit gravida rutrum quisque non. Hac habitasse platea dictumst quisque sagittis purus sit. Faucibus ornare suspendisse sed nisi lacus. Nulla porttitor massa id neque aliquam vestibulum. Ante in nibh mauris cursus mattis molestie a. Mi tempus imperdiet nulla malesuada.

File: content/guides/build-blog-using-contentlayer-mdx.mdx Copy Chapter

title: Build a blog using ContentLayer and MDX. date: 2022-11-18 Copy Chapter

Until now, trying to style an article, document, or blog post with Tailwind has been a tedious task that required a keen eye for typography and a lot of complex custom CSS.

By default, Tailwind removes all of the default browser styling from paragraphs, headings, lists and more. This ends up being really useful for building application UIs because you spend less time undoing user-agent styles, but when you really are just trying to style some content that came from a rich-text editor in a CMS or a markdown file, it can be surprising and unintuitive.

We get lots of complaints about it actually, with people regularly asking us things like:

Why is Tailwind removing the default styles on my h1 elements? How do I disable this? What do you mean I lose all the other base styles too?
We hear you, but we're not convinced that simply disabling our base styles is what you really want. You don't want to have to remove annoying margins every time you use a p element in a piece of your dashboard UI. And I doubt you really want your blog posts to use the user-agent styles either — you want them to look awesome, not awful.

The @tailwindcss/typography plugin is our attempt to give you what you actually want, without any of the downsides of doing something stupid like disabling our base styles.

It adds a new prose class that you can slap on any block of vanilla HTML content and turn it into a beautiful, well-formatted document:

<article class="prose">
  <h1>Garlic bread with cheese: What the science tells us</h1>
  
    For years parents have espoused the health benefits of eating garlic bread
    with cheese to their children, with the food earning such an iconic status
    in our culture that kids will often dress up as warm, cheesy loaf for
    Halloween.
  
  
    But a recent study shows that the celebrated appetizer may be linked to a
    series of rabies cases springing up around the country.
  
</article>

For more information about how to use the plugin and the features it includes, read the documentation.

What to expect from here on out Copy Chapter

What follows from here is just a bunch of absolute nonsense I've written to dogfood the plugin itself. It includes every sensible typographic element I could think of, like bold text, unordered lists, ordered lists, code blocks, block quotes, and even italics.

It's important to cover all of these use cases for a few reasons:

1. We want everything to look good out of the box.
2. Really just the first reason, that's the whole point of the plugin.
3. Here's a third pretend reason though a list with three items looks more realistic than a list with two items.

Now we're going to try out another header style.

Typography should be easy Copy Section

So that's a header for you — with any luck if we've done our job correctly that will look pretty reasonable.

Something a wise person once told me about typography is:

Typography is pretty important if you don't want your stuff to look like trash. Make it good then it won't be bad.

It's probably important that images look okay here by default as well:

Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of classical Latin literature from 45 BC, making it over 2000 years old.

Now I'm going to show you an example of an unordered list to make sure that looks good, too:

• So here is the first item in this list.
• In this example we're keeping the items short.
• Later, we'll use longer, more complex list items.

And that's the end of this section.

What if we stack headings? Copy Chapter

We should make sure that looks good, too. Copy Section

Sometimes you have headings directly underneath each other. In those cases you often have to undo the top margin on the second heading because it usually looks better for the headings to be closer together than a paragraph followed by a heading should be.

When a heading comes after a paragraph … Copy Section

When a heading comes after a paragraph, we need a bit more space, like I already mentioned above. Now let's see what a more complex list would look like.

• I often do this thing where list items have headings.

  For some reason I think this looks cool which is unfortunate because it's pretty annoying to get the styles right.

  I often have two or three paragraphs in these list items, too, so the hard part is getting the spacing between the paragraphs, list item heading, and separate list items to all make sense. Pretty tough honestly, you could make a strong argument that you just shouldn't write this way.

• Since this is a list, I need at least two items.

  I explained what I'm doing already in the previous list item, but a list wouldn't be a list if it only had one item, and we really want this to look realistic. That's why I've added this second list item so I actually have something to look at when writing the styles.

• It's not a bad idea to add a third item either.

  I think it probably would've been fine to just use two items but three is definitely not worse, and since I seem to be having no trouble making up arbitrary things to type, I might as well include it.

After this sort of list I usually have a closing statement or paragraph, because it kinda looks weird jumping right to a heading.

Code should look okay by default. Copy Chapter

I think most people are going to use highlight.js or Prism or something if they want to style their code blocks but it wouldn't hurt to make them look okay out of the box, even with no syntax highlighting.

Here's what a default tailwind.config.js file looks like at the time of writing:

module.exports = {
  purge: [],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}

Hopefully that looks good enough to you.

What about nested lists? Copy Section

Nested lists basically always look bad which is why editors like Medium don't even let you do it, but I guess since some of you goofballs are going to do it we have to carry the burden of at least making it work.

1. Nested lists are rarely a good idea.
   • You might feel like you are being really "organized" or something but you are just creating a gross shape on the screen that is hard to read.
   • Nested navigation in UIs is a bad idea too, keep things as flat as possible.
   • Nesting tons of folders in your source code is also not helpful.
2. Since we need to have more items, here's another one.
   • I'm not sure if we'll bother styling more than two levels deep.
   • Two is already too much, three is guaranteed to be a bad idea.
   • If you nest four levels deep you belong in prison.
3. Two items isn't really a list, three is good though.
   • Again please don't nest lists if you want people to actually read your content.
   • Nobody wants to look at this.
   • I'm upset that we even have to bother styling this.

The most annoying thing about lists in Markdown is that <li> elements aren't given a child `` tag unless there are multiple paragraphs in the list item. That means I have to worry about styling that annoying situation too.

• For example, here's another nested list.

  But this time with a second paragraph.

  • These list items won't have `` tags
  • Because they are only one line each

• But in this second top-level list item, they will.

  This is especially annoying because of the spacing on this paragraph.

  • As you can see here, because I've added a second line, this list item now has a `` tag.

    This is the second line I'm talking about by the way.

  • Finally here's another list item so it's more like a list.

• A closing list item, but with no nested list, because why not?

And finally a sentence to close off this section.

There are other elements we need to style Copy Chapter

I almost forgot to mention links, like this link to the Tailwind CSS website. We almost made them blue but that's so yesterday, so we went with dark gray, feels edgier.

We even included table styles, check it out:

We also need to make sure inline code looks good, like if I wanted to talk about `` elements or tell you the good news about @tailwindcss/typography.

Sometimes I even use `code` in headings Copy Section

Even though it's probably a bad idea, and historically I've had a hard time making it look good. This "wrap the code blocks in backticks" trick works pretty well though really.

Another thing I've done in the past is put a code tag inside of a link, like if I wanted to tell you about the tailwindcss/docs repository. I don't love that there is an underline below the backticks but it is absolutely not worth the madness it would require to avoid it.

We haven't used an `h4` yet

But now we have. Please don't use h5 or h6 in your content, Medium only supports two heading levels for a reason, you animals. I honestly considered using a before pseudo-element to scream at you if you use an h5 or h6.

We don't style them at all out of the box because h4 elements are already so small that they are the same size as the body copy. What are we supposed to do with an h5, make it smaller than the body copy? No thanks.

We still need to think about stacked headings though. Copy Section

Let's make sure we don't screw that up with `h4` elements, either.

Phew, with any luck we have styled the headings above this text and they look pretty good.

Let's add a closing paragraph here so things end with a decently sized block of text. I can't explain why I want things to end that way but I have to assume it's because I think things will look weird or unbalanced if there is a heading too close to the end of the document.

What I've written here is probably long enough, but adding this final sentence can't hurt.

GitHub Flavored Markdown Copy Chapter

I've also added support for GitHub Flavored Mardown using remark-gfm.

With remark-gfm, we get a few extra features in our markdown. Example: autolink literals.

A link like www.example.com or https://example.com would automatically be converted into an a tag.

This works for email links too: [email protected].

File: content/guides/using-next-auth-next-13.mdx Copy Chapter

title: Using NextAuth.js with Next.13 date: 2022-11-23 Copy Chapter

Until now, trying to style an article, document, or blog post with Tailwind has been a tedious task that required a keen eye for typography and a lot of complex custom CSS.

By default, Tailwind removes all of the default browser styling from paragraphs, headings, lists and more. This ends up being really useful for building application UIs because you spend less time undoing user-agent styles, but when you really are just trying to style some content that came from a rich-text editor in a CMS or a markdown file, it can be surprising and unintuitive.

We get lots of complaints about it actually, with people regularly asking us things like:

Why is Tailwind removing the default styles on my h1 elements? How do I disable this? What do you mean I lose all the other base styles too?
We hear you, but we're not convinced that simply disabling our base styles is what you really want. You don't want to have to remove annoying margins every time you use a p element in a piece of your dashboard UI. And I doubt you really want your blog posts to use the user-agent styles either — you want them to look awesome, not awful.

The @tailwindcss/typography plugin is our attempt to give you what you actually want, without any of the downsides of doing something stupid like disabling our base styles.

It adds a new prose class that you can slap on any block of vanilla HTML content and turn it into a beautiful, well-formatted document:

<article class="prose">
  <h1>Garlic bread with cheese: What the science tells us</h1>
  
    For years parents have espoused the health benefits of eating garlic bread
    with cheese to their children, with the food earning such an iconic status
    in our culture that kids will often dress up as warm, cheesy loaf for
    Halloween.
  
  
    But a recent study shows that the celebrated appetizer may be linked to a
    series of rabies cases springing up around the country.
  
</article>

For more information about how to use the plugin and the features it includes, read the documentation.

What to expect from here on out Copy Chapter

What follows from here is just a bunch of absolute nonsense I've written to dogfood the plugin itself. It includes every sensible typographic element I could think of, like bold text, unordered lists, ordered lists, code blocks, block quotes, and even italics.

It's important to cover all of these use cases for a few reasons:

1. We want everything to look good out of the box.
2. Really just the first reason, that's the whole point of the plugin.
3. Here's a third pretend reason though a list with three items looks more realistic than a list with two items.

Now we're going to try out another header style.

Typography should be easy Copy Section

So that's a header for you — with any luck if we've done our job correctly that will look pretty reasonable.

Something a wise person once told me about typography is:

Typography is pretty important if you don't want your stuff to look like trash. Make it good then it won't be bad.

It's probably important that images look okay here by default as well:

Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of classical Latin literature from 45 BC, making it over 2000 years old.

Now I'm going to show you an example of an unordered list to make sure that looks good, too:

• So here is the first item in this list.
• In this example we're keeping the items short.
• Later, we'll use longer, more complex list items.

And that's the end of this section.

What if we stack headings? Copy Chapter

We should make sure that looks good, too. Copy Section

Sometimes you have headings directly underneath each other. In those cases you often have to undo the top margin on the second heading because it usually looks better for the headings to be closer together than a paragraph followed by a heading should be.

When a heading comes after a paragraph … Copy Section

When a heading comes after a paragraph, we need a bit more space, like I already mentioned above. Now let's see what a more complex list would look like.

• I often do this thing where list items have headings.

  For some reason I think this looks cool which is unfortunate because it's pretty annoying to get the styles right.

  I often have two or three paragraphs in these list items, too, so the hard part is getting the spacing between the paragraphs, list item heading, and separate list items to all make sense. Pretty tough honestly, you could make a strong argument that you just shouldn't write this way.

• Since this is a list, I need at least two items.

  I explained what I'm doing already in the previous list item, but a list wouldn't be a list if it only had one item, and we really want this to look realistic. That's why I've added this second list item so I actually have something to look at when writing the styles.

• It's not a bad idea to add a third item either.

  I think it probably would've been fine to just use two items but three is definitely not worse, and since I seem to be having no trouble making up arbitrary things to type, I might as well include it.

After this sort of list I usually have a closing statement or paragraph, because it kinda looks weird jumping right to a heading.

Code should look okay by default. Copy Chapter

I think most people are going to use highlight.js or Prism or something if they want to style their code blocks but it wouldn't hurt to make them look okay out of the box, even with no syntax highlighting.

Here's what a default tailwind.config.js file looks like at the time of writing:

module.exports = {
  purge: [],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}

Hopefully that looks good enough to you.

What about nested lists? Copy Section

Nested lists basically always look bad which is why editors like Medium don't even let you do it, but I guess since some of you goofballs are going to do it we have to carry the burden of at least making it work.

1. Nested lists are rarely a good idea.
   • You might feel like you are being really "organized" or something but you are just creating a gross shape on the screen that is hard to read.
   • Nested navigation in UIs is a bad idea too, keep things as flat as possible.
   • Nesting tons of folders in your source code is also not helpful.
2. Since we need to have more items, here's another one.
   • I'm not sure if we'll bother styling more than two levels deep.
   • Two is already too much, three is guaranteed to be a bad idea.
   • If you nest four levels deep you belong in prison.
3. Two items isn't really a list, three is good though.
   • Again please don't nest lists if you want people to actually read your content.
   • Nobody wants to look at this.
   • I'm upset that we even have to bother styling this.

The most annoying thing about lists in Markdown is that <li> elements aren't given a child `` tag unless there are multiple paragraphs in the list item. That means I have to worry about styling that annoying situation too.

• For example, here's another nested list.

  But this time with a second paragraph.

  • These list items won't have `` tags
  • Because they are only one line each

• But in this second top-level list item, they will.

  This is especially annoying because of the spacing on this paragraph.

  • As you can see here, because I've added a second line, this list item now has a `` tag.

    This is the second line I'm talking about by the way.

  • Finally here's another list item so it's more like a list.

• A closing list item, but with no nested list, because why not?

And finally a sentence to close off this section.

There are other elements we need to style Copy Chapter

I almost forgot to mention links, like this link to the Tailwind CSS website. We almost made them blue but that's so yesterday, so we went with dark gray, feels edgier.

We even included table styles, check it out:

We also need to make sure inline code looks good, like if I wanted to talk about `` elements or tell you the good news about @tailwindcss/typography.

Sometimes I even use `code` in headings Copy Section

Even though it's probably a bad idea, and historically I've had a hard time making it look good. This "wrap the code blocks in backticks" trick works pretty well though really.

Another thing I've done in the past is put a code tag inside of a link, like if I wanted to tell you about the tailwindcss/docs repository. I don't love that there is an underline below the backticks but it is absolutely not worth the madness it would require to avoid it.

We haven't used an `h4` yet

But now we have. Please don't use h5 or h6 in your content, Medium only supports two heading levels for a reason, you animals. I honestly considered using a before pseudo-element to scream at you if you use an h5 or h6.

We don't style them at all out of the box because h4 elements are already so small that they are the same size as the body copy. What are we supposed to do with an h5, make it smaller than the body copy? No thanks.

We still need to think about stacked headings though. Copy Section

Let's make sure we don't screw that up with `h4` elements, either.

Phew, with any luck we have styled the headings above this text and they look pretty good.

Let's add a closing paragraph here so things end with a decently sized block of text. I can't explain why I want things to end that way but I have to assume it's because I think things will look weird or unbalanced if there is a heading too close to the end of the document.

What I've written here is probably long enough, but adding this final sentence can't hurt.

GitHub Flavored Markdown Copy Chapter

I've also added support for GitHub Flavored Mardown using remark-gfm.

With remark-gfm, we get a few extra features in our markdown. Example: autolink literals.

A link like www.example.com or https://example.com would automatically be converted into an a tag.

This works for email links too: [email protected].

File: content/docs/documentation/code-blocks.mdx Copy Chapter

title: Code Blocks Copy Chapter

The code blocks on the documentation site and the blog are powered by rehype-pretty-code. The syntax highlighting is done using shiki.

It has the following features:

1. Beautiful code blocks with syntax highlighting.
2. Support for VS Code themes.
3. Works with hundreds of languages.
4. Line and word highlighting.
5. Support for line numbers.
6. Show code block titles using meta strings.

Example Copy Chapter

import { withContentlayer } from "next-contentlayer"

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  images: {
    domains: ["avatars.githubusercontent.com"],
  },
  experimental: {
    appDir: true,
    serverComponentsExternalPackages: ["@prisma/client"],
  },
}

export default withContentlayer(nextConfig)

Title Copy Chapter

```ts title="path/to/file.ts"
// Code here
```

Line Highlight Copy Chapter

```ts {1,3-6}
// Highlight line 1 and line 3 to 6
```

Word Highlight Copy Chapter

```ts /shadcn/
// Highlight the word shadcn.
```

Line Numbers Copy Chapter

```ts showLineNumbers
// This will show line numbers.
```

File: content/docs/documentation/components.mdx Copy Chapter

title: Components Copy Chapter

The following components are available out of the box for use in Markdown.

If you'd like to build and add your own custom components, see the Custom Components section below.

Built-in Components Copy Chapter

1. Callout Copy Section

<Callout type=" default | warning | danger ">

This is a default callout. You can embed **Markdown** inside a `callout`.

</Callout>

2. Card Copy Section

<Card href="#">

#### Heading

You can use **markdown** inside cards.

</Card>

You can also use HTML to embed cards in a grid.

<Card href="#">
    #### Card One 
    You can use **markdown** inside cards.
  </Card>

  <Card href="#">
    #### Card Two 
    You can also use `inline code` and code blocks.
  </Card>

Custom Components Copy Chapter

You can add your own custom components using the components props from useMDXComponent.

import { Callout } from "@/components/callout"
import { CustomComponent } from "@/components/custom"

const components = {
  Callout,
  CustomComponent,
}

export function Mdx({ code }) {
  const Component = useMDXComponent(code)

  return (
    
      <Component components={components} />
    
  )
}

Once you've added your custom component, you can use it in MDX as follows:

<CustomComponent propName="value" />

HTML Elements Copy Chapter

You can overwrite HTML elements using the same technique above.

const components = {
  Callout,
  CustomComponent,
  hr: ({ ...props }) => <hr className="my-4 border-slate-200 md:my-6" />,
}

This will overwrite the <hr /> tag or --- in Mardown with the HTML output above.

Styling Copy Chapter

Tailwind CSS classes can be used inside MDX for styling.

This text will be red.

Make sure you have configured the path to your content in your tailwind.config.js file:

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./app/**/*.{ts,tsx}",
    "./components/**/*.{ts,tsx}",
    "./content/**/*.{md,mdx}",
  ],
}

File: content/docs/documentation/index.mdx Copy Chapter

title: Documentation Copy Chapter

Taxonomy includes a documentation site built using Contentlayer and MDX.

Features Copy Chapter

It comes with the following features out of the box:

1. Write content using MDX.
2. Transform and validate content using Contentlayer.
3. MDX components such as <Callout /> and <Card />.
4. Support for table of contents.
5. Custom navigation with prev and next pager.
6. Beautiful code blocks using rehype-pretty-code.
7. Syntax highlighting using shiki.
8. Built-in search (in progress).
9. Dark mode (in progress).

How is it built Copy Chapter

Click on a section below to learn how the documentation site built.

File: content/docs/documentation/style-guide.mdx Copy Chapter

title: Style Guide Copy Chapter

Until now, trying to style an article, document, or blog post with Tailwind has been a tedious task that required a keen eye for typography and a lot of complex custom CSS.

By default, Tailwind removes all of the default browser styling from paragraphs, headings, lists and more. This ends up being really useful for building application UIs because you spend less time undoing user-agent styles, but when you really are just trying to style some content that came from a rich-text editor in a CMS or a markdown file, it can be surprising and unintuitive.

We get lots of complaints about it actually, with people regularly asking us things like:

Why is Tailwind removing the default styles on my h1 elements? How do I disable this? What do you mean I lose all the other base styles too?
We hear you, but we're not convinced that simply disabling our base styles is what you really want. You don't want to have to remove annoying margins every time you use a p element in a piece of your dashboard UI. And I doubt you really want your blog posts to use the user-agent styles either — you want them to look awesome, not awful.

The @tailwindcss/typography plugin is our attempt to give you what you actually want, without any of the downsides of doing something stupid like disabling our base styles.

It adds a new prose class that you can slap on any block of vanilla HTML content and turn it into a beautiful, well-formatted document:

<article class="prose">
  <h1>Garlic bread with cheese: What the science tells us</h1>
  
    For years parents have espoused the health benefits of eating garlic bread
    with cheese to their children, with the food earning such an iconic status
    in our culture that kids will often dress up as warm, cheesy loaf for
    Halloween.
  
  
    But a recent study shows that the celebrated appetizer may be linked to a
    series of rabies cases springing up around the country.
  
</article>

For more information about how to use the plugin and the features it includes, read the documentation.

What to expect from here on out Copy Chapter

What follows from here is just a bunch of absolute nonsense I've written to dogfood the plugin itself. It includes every sensible typographic element I could think of, like bold text, unordered lists, ordered lists, code blocks, block quotes, and even italics.

It's important to cover all of these use cases for a few reasons:

1. We want everything to look good out of the box.
2. Really just the first reason, that's the whole point of the plugin.
3. Here's a third pretend reason though a list with three items looks more realistic than a list with two items.

Now we're going to try out another header style.

Typography should be easy Copy Section

So that's a header for you — with any luck if we've done our job correctly that will look pretty reasonable.

Something a wise person once told me about typography is:

Typography is pretty important if you don't want your stuff to look like trash. Make it good then it won't be bad.

It's probably important that images look okay here by default as well:

Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of classical Latin literature from 45 BC, making it over 2000 years old.

Now I'm going to show you an example of an unordered list to make sure that looks good, too:

• So here is the first item in this list.
• In this example we're keeping the items short.
• Later, we'll use longer, more complex list items.

And that's the end of this section.

What if we stack headings? Copy Chapter

We should make sure that looks good, too. Copy Section

Sometimes you have headings directly underneath each other. In those cases you often have to undo the top margin on the second heading because it usually looks better for the headings to be closer together than a paragraph followed by a heading should be.

When a heading comes after a paragraph … Copy Section

When a heading comes after a paragraph, we need a bit more space, like I already mentioned above. Now let's see what a more complex list would look like.

• I often do this thing where list items have headings.

  For some reason I think this looks cool which is unfortunate because it's pretty annoying to get the styles right.

  I often have two or three paragraphs in these list items, too, so the hard part is getting the spacing between the paragraphs, list item heading, and separate list items to all make sense. Pretty tough honestly, you could make a strong argument that you just shouldn't write this way.

• Since this is a list, I need at least two items.

  I explained what I'm doing already in the previous list item, but a list wouldn't be a list if it only had one item, and we really want this to look realistic. That's why I've added this second list item so I actually have something to look at when writing the styles.

• It's not a bad idea to add a third item either.

  I think it probably would've been fine to just use two items but three is definitely not worse, and since I seem to be having no trouble making up arbitrary things to type, I might as well include it.

After this sort of list I usually have a closing statement or paragraph, because it kinda looks weird jumping right to a heading.

Code should look okay by default. Copy Chapter

I think most people are going to use highlight.js or Prism or something if they want to style their code blocks but it wouldn't hurt to make them look okay out of the box, even with no syntax highlighting.

Here's what a default tailwind.config.js file looks like at the time of writing:

module.exports = {
  purge: [],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}

Hopefully that looks good enough to you.

What about nested lists? Copy Section

Nested lists basically always look bad which is why editors like Medium don't even let you do it, but I guess since some of you goofballs are going to do it we have to carry the burden of at least making it work.

1. Nested lists are rarely a good idea.
   • You might feel like you are being really "organized" or something but you are just creating a gross shape on the screen that is hard to read.
   • Nested navigation in UIs is a bad idea too, keep things as flat as possible.
   • Nesting tons of folders in your source code is also not helpful.
2. Since we need to have more items, here's another one.
   • I'm not sure if we'll bother styling more than two levels deep.
   • Two is already too much, three is guaranteed to be a bad idea.
   • If you nest four levels deep you belong in prison.
3. Two items isn't really a list, three is good though.
   • Again please don't nest lists if you want people to actually read your content.
   • Nobody wants to look at this.
   • I'm upset that we even have to bother styling this.

The most annoying thing about lists in Markdown is that <li> elements aren't given a child `` tag unless there are multiple paragraphs in the list item. That means I have to worry about styling that annoying situation too.

• For example, here's another nested list.

  But this time with a second paragraph.

  • These list items won't have `` tags
  • Because they are only one line each

• But in this second top-level list item, they will.

  This is especially annoying because of the spacing on this paragraph.

  • As you can see here, because I've added a second line, this list item now has a `` tag.

    This is the second line I'm talking about by the way.

  • Finally here's another list item so it's more like a list.

• A closing list item, but with no nested list, because why not?

And finally a sentence to close off this section.

There are other elements we need to style Copy Chapter

I almost forgot to mention links, like this link to the Tailwind CSS website. We almost made them blue but that's so yesterday, so we went with dark gray, feels edgier.

We even included table styles, check it out:

We also need to make sure inline code looks good, like if I wanted to talk about `` elements or tell you the good news about @tailwindcss/typography.

Sometimes I even use `code` in headings Copy Section

Even though it's probably a bad idea, and historically I've had a hard time making it look good. This "wrap the code blocks in backticks" trick works pretty well though really.

Another thing I've done in the past is put a code tag inside of a link, like if I wanted to tell you about the tailwindcss/docs repository. I don't love that there is an underline below the backticks but it is absolutely not worth the madness it would require to avoid it.

We haven't used an `h4` yet

But now we have. Please don't use h5 or h6 in your content, Medium only supports two heading levels for a reason, you animals. I honestly considered using a before pseudo-element to scream at you if you use an h5 or h6.

We don't style them at all out of the box because h4 elements are already so small that they are the same size as the body copy. What are we supposed to do with an h5, make it smaller than the body copy? No thanks.

We still need to think about stacked headings though. Copy Section

Let's make sure we don't screw that up with `h4` elements, either.

Phew, with any luck we have styled the headings above this text and they look pretty good.

Let's add a closing paragraph here so things end with a decently sized block of text. I can't explain why I want things to end that way but I have to assume it's because I think things will look weird or unbalanced if there is a heading too close to the end of the document.

What I've written here is probably long enough, but adding this final sentence can't hurt.

GitHub Flavored Markdown Copy Chapter

I've also added support for GitHub Flavored Mardown using remark-gfm.

With remark-gfm, we get a few extra features in our markdown. Example: autolink literals.

A link like www.example.com or https://example.com would automatically be converted into an a tag.

This works for email links too: [email protected].

File: content/docs/in-progress.mdx Copy Chapter

title: Not Implemented Copy Chapter