contentlayerdev / contentlayerdev/contentlayer

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

Offen
#464 4 Kommentare 9 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
help wanted meta: never-stale needs-research
Vorherrschende Sprache
TypeScript
Sterne
3.5k
Forks
192
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

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

Beitragsleitfaden

Beitragsleitfaden öffnen

Rechercherichtung

Beginne mit createContentlayerPlugin() und der next-contentlayer-Dokumentation, einschließlich der Option configPath und des Verhaltens rund um tsconfig.json. Reproduziere das apps/my-nextjs-app-Monorepo-Szenario mit pnpm nx serve und definiere den Abschluss als dokumentierte Konfiguration für Konfigurations- und Ausgabepfade sowie saubere Unterstützung für mehrere Apps ohne verwirrende Konsolenausgabe.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
nextjs, typescript
Bereich
build-system, documentation, tooling
Issue-Typ
Feature
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
38/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.