feat: parseReadme / better feature sections

[aheissenberger]

Problem:

the existing function to add a description of a feature to the README.md are very limited and add not needed extra level 1 headers.

Suggestion:

1. the categories defined in features should be used to structure the README
2. only when there is content in a category the section with the category as a header is shown
3. the order of the categories should be similar to bait.dev and should reflect a full stack from frontend to the backend
4. the order in a category section is defined by the order the templates get overwritten (defined in package.json) but in reversed order - e.g. 1. shadcn/ui, 2. tailwind
5. the function addFeature(content: string) will grab the category and name of the feature as defined in features.ts and creates the required main headings

[magne4000]

I'm totally open to improving the README parser.

the categories defined in features should be used to structure the README

I agree, I started with a hard-coded list of headers for simplicity, but we should be able to customize this more freely

only when there is content in a category the section with the category as a header is shown

👍

the order of the categories should be similar to bait.dev and should reflect a full stack from frontend to the backend

This is a great idea

the order in a category section is defined by the order the templates get overwritten (defined in package.json) but in reversed order - e.g. 1. shadcn/ui, 2. tailwind

This seems sensible

the function addFeature(content: string) will grab the category and name of the feature as defined in features.ts and creates the required main headings

👍

This all around seems like a huge improvement over the existing state of the README parser. Would you be willing to implement this?

[aheissenberger]

Yes I can do the implementation.

@magne4000 do you have any preference for a markup parsing library or should we stay with the existing manual text parsing approach?

[magne4000]

Using a markup parsing library is fine, but it needs to have a small bundled size, as it will be bundled entirely in @batijs/core. If there are multiple contenders, we can discuss which one we want to use here.