ignatiusmb / aubade Goto Github PK

When defining metadata, we could also use numbers as the keys and sometimes it will behave as if it was an array, foo:0 ... foo:4. It will be converted into an object and could index them just like an array, but we can't do any native array methods like map or filter to do the manipulation. It would be nice if it was smart enough to automatically convert these array-like keys into actual arrays on compile.

Letting user add their own additional languages that is going to be highlighted would also reduce the bundle size on initial install.

We should try to reduce install size, and especially bundle size by separating the exports, allowing more user-extensible options (#35) would be really nice as well so we don't really ship potentially unused code.

Following the idea of os.walk() from Python, could it somehow be implemented here to scan a directory and continue to scan the directory or parse the file if it encounters either one of them. This would remove the need for end-user to import and run a readdirSync by themselves where in this case, they would need to handle the file/directory check by themselves. It would also only work for one-level deep directories and would need multiple calls for nested ones, which is not the best ease of use.

By implementing this, its usability would drastically increase and will cover a lot of use cases. Of course, this would be put behind an option. Would it be preferable to have it turned on or off by default?

parseDir({ recurse?: boolean })

The end result would still be an array. It'll probably have to be adjusted for the mix of files and directories. Perhaps, another property to check whether it's a direct file or needs to be looped over again (parsed directory).

Directory import is not supported resolving ES modules, upgrade to TS 4.7+ and use Node16 module resolution

Describe the bug
There's a skipped test in the workspace/marqua/src/core that fails when enabled. It treats nested maps inside sequences with spaces as if it were a map under the sequence instead of within it.

Expected behavior
The test should pass, it should behave the no different than the other test that were separated with tabs.

Use issue forms instead

Is your feature request related to a problem? Please describe.
When writing headings, it would be nice if we can indicate a way for the parser to generate a hash from a selected range instead of the whole heading.

Describe the solution you'd like
Add a delimiter $(...) that can be used inside the headings, such that we can get #hello-world from the following markdown

## 1 / 2 / 3 | $(hello world)

Describe alternatives you've considered
Use brackets [...] but that would conflict with links and images, and would be harder to use literally with escaping and such.

The parser trims some characters out from the key depending on how much trailing whitespaces a map contains after the colon

The latest version (0.2.1) seems to break forge.types and doesn't cast types as Input/Output

If minimal is undefined or false, content type is MarquaData while it is actually a string

Putting an empty array as a placeholder inside the front matter generates an array with a single item inside, which is an empty string

---
tags: []
---

The above results in

{ tags: [ '' ] }

#12 adds a new feature for automatically injecting created and modified date stamp by checking the file stats using node fs. The problem is, file stats from fs is incredibly inconsistent and will vary across cloned repos and environments. It might be better to just remove it altogether.

Precedes #6

Svelte now supports dynamic elements through https://svelte.dev/docs#template-syntax-svelte-element, it's time bump up the priority and implement individual token parsing and rendering.

Rather than trying to group headings based on the previous heading to determine its parent, we could simply add a level property that tells the consumer what level the heading is so they can style it accordingly without making things overcomplicated.

Is your feature request related to a problem? Please describe.
It's limiting to be able to only read from a file and parse it that way.

Describe the solution you'd like
It would be nice to have a standalone parse function that takes in a string and returns the results (metadata and content).

Describe alternatives you've considered
Leave it as is.

Additional context
This might also be part of #37

Is your feature request related to a problem? Please describe.
The compiler is heavily coupled with fs, which is a node.js module. There's no other way to produce the same output without relying on it reading a file. It was originally designed to deny usage in browser as the markdown parser and highlighter are considered quite heavy to be bundled and shipped to client browsers, which is still a good thing, but we can probably shim some methods and refactor them to be used individually.

Describe the solution you'd like

• Redesign the compiler stuff which might take a long time, but it may result to a better flow.
• Refactor and create a separate module for each possible usage.

Describe alternatives you've considered
Do nothing and force the user to write the contents to a file first, or perhaps possibility to read from a Buffer.

Additional context
Future features and enhancements will rely heavily and might not even be possible before this is implemented first.

Carriage return \r formatted in files from Windows does not get taken into account and causes the key to be sliced in the result

Ability to pass in a siblings option that could format the sibling object. Will definitely need to receive a callback that returns the formatted item, and maybe another callback to check the breakpoint. Putting in the code from mauss.dev as reference.

function fillSiblings<T extends Child>(
	articles: T[],
	base: string,
	breakpoint?: (next: T) => boolean
): T[] {
	for (let i = 0; i < articles.length; i++) {
		if (!articles[i]['siblings']) articles[i]['siblings'] = {};
		const [prev, next] = [articles[i - 1], articles[i + 1]];
		if (prev) articles[i]['siblings']['prev'] = { slug: base + prev.slug, title: prev.title };
		if (breakpoint && breakpoint(next)) return articles;
		if (next) articles[i]['siblings']['next'] = { slug: base + next.slug, title: next.title };
	}
	return articles;
}

The default value will definitely be undefined as it will not generate siblings by default. Passed options however, might either receive an object or just a single callback function. More inclined to the first one as the latter seems overcomplicated and inconvenient.

siblings: {
  item: ({ prev, next }) => any,
  breakpoint: (next: T) => boolean
}

Only fixed set of types are exposed but it doesn't really describe the actual file's front matter. Ideally, these front matter properties are available to use after compilation. Right now, they need to be manually typed by the user so any changes or updates to the front matter needs to be updated to the type as well, which is nice strictly speaking, but not ideal as this should generally be dynamic.

The general idea is to

1. Generate .d.ts from JSON object, straight from the return value of compile and traverse, which means a separate function. Or even inside of them, passed as an option.
2. Place generated *.d.ts in a locally cached folder (needs to be gitignored), or inside node_modules (if it's possible) and somehow make TypeScript aware of it and correctly captures the types in relation to the directory path, or just make them globally available to be imported

When there's multiple headings with the same content, automatically make the generated slugs unique

Is your feature request related to a problem? Please describe.
Getting the filename from breadcrumb gets repetitive overtime with no easy way to around it. Currently, breadcrumb is just passing the split up paths as an array of string. Any pathname will be passed directly to the user with the filename as the last item, and the first couple of items essentially useless.

const path = 'src/content/posts/my-category/the-post-slug.md';
compile(path, ({ breadcrumb }) => {
  // ['src', 'content', 'posts', 'my-category', 'the-post-slug.md']
  const [category, filename] = breadcrumb.slice(-2);
  // or; const filename = breadcrumb[breadcrumb.length - 1];
});

There is no way to get the filename without slicing or writing that long property accessors. The current implementation delegates the responsibility of extracting the filename to the users, and this happens too frequently without any apparent shortcut. Sure this may give a lot of flexibility and consistency between folders as the first couple of items are expected to be the same across functions. But, the same could also be said for the reversed paths array.

Describe the solution you'd like
A way to cleanly access path names by reversing the path array order, this will enable stuff like

const path = 'src/content/posts/my-category/the-post-slug.md';
compile(path, ({ breadcrumb }) => {
  // ['the-post-slug.md', 'my-category', 'posts', 'content', 'src']
  const [filename, category, ...rest] = breadcrumb;
  // or; const filename = breadcrumb[0];
});
// or even better
compile(path, ({ breadcrumb: [filename, category] }) => {
  // filename: 'the-post-slug.md'
  // category: 'my-category'
});

Describe alternatives you've considered
Do nothing and let the users index as usual.