[plugin-markdown] better route config options

[Apollinaire]

The markdown plugin has a nice and simple way to configure how it deals with content, by just passing the name of the routes you want it to handle. However, this "magic" limits the devs on the way they organize the content inside their repository: they simply can't take their markdown files out of src/routes/[route]/ . This feels similar to Nextjs' routing system. It's not bad, but it has its limitations, and when for Nextjs it's justified by the fact that this is core to their build system, that they do a lot of optimizations on top of it, I think it's not justified for the markdown plugin.
I'd like to discuss the possibilities there are to change the config so that the plugin can handle markdown content anywhere inside the repository, and link it with a route.
Here is a proposal: the routes property can accept an array of objects of the following form:

const routes = [
  { content : [ "articles/travelling/*"], route: "travelling" }, // content is a list of globs
  { content : [ "articles/**/*.md", route: "allArticles"},
]

For backwards compatibility and ease of use, the current configuration can be kept as a shorthand for the following :

{ content: ["src/routes/travelling/*.md"], route: "travelling" }

Tell me what you think of this API, maybe improve it, and I can work on a PR

[nickreese]

I like the idea.

I’d suggest we explore a plain object for the config where the key is the route name and the value is the array of content strings.

This will prevent having to parse the array and look for multiple definitions for the same route and simplify onboarding / documentation.

[Apollinaire]

I like having an object to avoid deduplicating routes, however I think having an array of content strings limits the evolution of the config. It's easy to add a key to an object, it will never break other people's config if you make that key optional. If you just pass an array of strings, you can't add anything later without a breaking change, or at least some polymorphism like we are doing here. Of course you can always use another key than routes, but I think it's quite a good name.

[nickreese]

@Apollinaire I'm with you on using an array. I think my usecase doesn't match the broader needs. Let me know how I can support.

[noxasch]

I like the idea.

I’d suggest we explore a plain object for the config where the key is the route name and the value is the array of content strings.

This will prevent having to parse the array and look for multiple definitions for the same route and simplify onboarding / documentation.

IMO this is a good idea as the route config allow us to separate the content and source code. So the config should look like this, where the route is as the content key if i follow it right as @nickreese said

{ 
  route: ['travelling', 'allArticles']
  content: { 
      travelling: "articles/travelling/*",
      allArticles: "articles/**/*.md"
  }
}

[nickreese]

Would 100% accept a PR for this if you wanted to take a shot at it. Just haven’t had a chance to work on it.

I do like the structure you outline even if we need polymorphism in the future because it simplifies onboarding. We may want to document glob excludes so users don’t end up with duplicate content.

[noxasch]

I'm not sure about allArticles use cases though, i just took it to show example of multiple route. But If the goals is to group all article into one, we can look for other method for that specific purpose like utilizing hooks or routes.

[nickreese]

@noxasch 100% agree. I think it is bad practice to do an allArticles and was more taking it to mean that articles can live anywhere.

We could possibly track the files loaded and if files are duplicated throw an error about duplicate content.

As it currently stands all of the markdown is on the data object IIRC so in most cases it won't be needed.