out folder missing again

[miptctx]

There was similar issue #398 and it was fixed by changing config.mjs file. But now issue appeared again with valid config.mjs file content.

I am using Ubuntu 22.04.2 LTS, node-v16.15.0-linux-x64 and node-v18.16.1-linux-x64 (both do not work).

My config.mjs content:

const config = {
  title: "title",
  description: "description",
  author: "miptcts",
  authorLogo: "/images/logo.svg",
  domain: "https://my.dom",
  // links to the pages you want to link to in the navbar and in the footer
  navLinks: [{ href: "/about", name: "About" }],
};

export default config;

When I execute npx flowershow@latest export command I get such output:

> flowershow@2.0.3 export
> npm run build && next export

> flowershow@2.0.3 prebuild
> npm run generate

> flowershow@2.0.3 generate
> cross-env NODE_OPTIONS="--experimental-json-modules --experimental-modules" node -r esbuild-register ./scripts/postbuild.mjs

Sitemap generated...

> flowershow@2.0.3 build
> next build

info  - Skipping linting
info  - Checking validity of types...
info  - Creating an optimized production build...
info  - Compiled successfully
info  - Collecting page data...
info  - Generating static pages (0/55)
info  - Generating static pages (13/55)
info  - Generating static pages (27/55)
info  - Generating static pages (41/55)
info  - Generating static pages (55/55)

But after this command has finished, I see 3 node processes that are still launched in my system:

$ ps -A | grep node
 610277 pts/5    00:00:11 node
 610284 pts/5    00:00:01 node
 610291 pts/5    00:00:01 node

If I will launch this command again, I already get 6 node processes launched:

$ ps -A | grep node
 610277 pts/5    00:00:11 node
 610284 pts/5    00:00:01 node
 610291 pts/5    00:00:01 node
 610602 pts/5    00:00:10 node
 610609 pts/5    00:00:01 node
 610616 pts/5    00:00:01 node

And so on.

And no out directory in .flowershow of cource. But there is .next folder.

[luccasmmg]

I couldn't reproduce your error by copying and pasting your config.mjs file, could you provide a minimal reproducible example in the form of a git repo? Which i can clone and check it?

[miptctx]

I couldn't reproduce your error by copying and pasting your config.mjs file, could you provide a minimal reproducible example in the form of a git repo? Which i can clone and check it?

I have found the issue. If you will create raw project that contains only one index.md file with next content:

<->

then this issue is reproduced.

So the <-> string crashes the app.

But more over, the strings <- and < also crash it. So it looks the flowershow app does not like < bracket.

And one more investigation. If the index.md contains such body the app does not crash:

< hello

But this body crashes the app:

<hello

The difference is space after < bracket. If there is space - it works, if there is no space - it does not.

[demenech]

@miptctx this makes sense!

I believe MDX may be interpreting the < and > as special syntax, I've seen this before.

I'm not sure when we are going to fix this, but my suggestion is that for now if you really need the < you can try escaping it e.g.:

{'<'}hello

---

@olayway do you have any input here on how we could escape this special character by default and avoid this issue on Flowershow?

CC: @luccasmmg

[luccasmmg]

Its pretty much what Demenech mentioned it, Flowershow interprets everything as mdx and in mdx the < is reserved for calling jsx components.

[miptctx]

@olayway do you have any input here on how we could escape this special character by default and avoid this issue on Flowershow?

CC: @luccasmmg

It is interesting how obsidian process this bracket because it shows it well. Does it work by another way?

[demenech]

It is interesting how obsidian process this bracket because it shows it well. Does it work by another way?

I believe Obsidian doesn't use MDX but rather markdown extended with plugins.

[rufuspollock]

FIXED. I believe we got to the source of the issue which is the lack of support for < and > characters at a the moment in the source markdown.

We probably want an FAQ about this.