Poor/broken monorepo DX: can't specify .contentlayer/ output path, no docs for custom config path

Abierto
#464 4 comentarios 9 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
38/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
nextjs, typescript

Línea de trabajo

Comienza con createContentlayerPlugin() y la documentación de next-contentlayer, incluida la opción configPath y el comportamiento relacionado con tsconfig.json. Reproduce el escenario de monorepo apps/my-nextjs-app con pnpm nx serve y define la finalización como una configuración documentada para las rutas de configuración y salida, además de un soporte limpio para múltiples apps sin una salida de consola confusa.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

help wanted meta: never-stale needs-research

I tried getting Contentlayer rolling in an nx monorepo and found the developer experience to be poor.

I'm creating an issue to potentially influence the roadmap per the project website.
Contentlayer seems like a decent approach to supporting mdx that covers many use-cases so it'd be great to use it.

If you want to make this issue about one thing: developers should be able to configure the .contentlayer output location such that multiple sites/apps can be cleanly supported.

Context

In a monorepo a developer may have a nextjs blog/website/app at apps/my-app-name or packages/my-app-name.
(or even in an even deeper nested path in really large projects)

A given monorepo may house many different apps and libraries.

Developer Requirements

Contentlayer should not "take over" a project's root folder unless configured to do so, and it should support a monorepo where there may be several apps that use it and others that do not. An organization might have respective blog, product documentation, and marketing websites, each with their own MDX content; an individual might have multiple blogs.

  • a way to specify the path to the .contentlayer output dir for a given website/app that uses it
  • a straightforward and documented way to specify where the contentlayer config file is
  • contentlayer to consider where tsconfig.json is based on the path to its config (and/or specify a custom path to tsconfig)
    • right now contentlayer looks in the root of the project folder vs. where the config file is
    • nx apps have a tsconfig.json in their respective folders (it extends tsconfig.base.json in monorepo root)

Its ok if that's the default behaviour / happy path is no monorepo however I think there should be ways to support them far more elegantly.

In many cases would be best to be best to house everything together in each app's respective folder: the website content mdx, the contentlayer output, and the app itself.

In other cases a dev might prefer paths for content at the root of the project folder e.g. .contentlayer/ with subfolders for each app, content/ with subfolders for each app's content, etc off the project root.

Acceptance

Consider the scenario where a dev runs pnpm nx serve my-nextjs-app that's housed in apps/my-nextjs-app and everything is clean, organized, and plays nice and the console output isn't filled with confused contentlayer barf.

Documentation Issues

It is not well-documented that I can use createContentlayerPlugin() in next config to specify a configPath.

The docs at https://www.contentlayer.dev/docs/reference/next-contentlayer don't mention any of the "non default configuration options" but mention the existence. I had to find that out from looking at issue comments and PR's e.g. https://github.com/contentlayerdev/contentlayer/pull/248

Lenguaje dominante
TypeScript
Estrellas
3.5k
Forks
192
Métricas de merge de PR
Sin PR fusionados en 30 d

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de contentlayerdev/contentlayer

Todos los issues de contentlayerdev/contentlayer

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.