Return a VFile with an appropriate extension in the path

[altano]

Initial checklist

• [X] I read the support docs
• [X] I read the contributing guide
• [X] I agree to follow the code of conduct
• [X] I searched issues and couldn’t find anything (or linked relevant results below)

Problem

The path of the vfile returned by compile is the same as the markdown vfile passed in, and therefore has an extension of .md or .mdx. This is a little strange because the point of the compiler is for the returned vfile to be js. I assume this is just a tiny oversight and not intentional behavior.

Solution

If that's the case, I would humbly request that the path of the returned vfile have the extension changed to .js to reflect the compiled content in that vfile.

Alternatives

An alternative solution would be to have a blank path entirely, so that something grabbing the returned vfile would not be able to make bad assumptions about the path, which is better than nothing.

[wooorm]

Heya! Probably a good idea! At the point where I'd wonder what lines, practically, you suggest changing!

[wooorm]

Hmm, thinking about this more, I no longer think this is a good idea.

file.path is the input file path. We could indeed change the extension. But chances are, you’d want to store the file somewhere else too. Or use I dunno .mjs or no extension.

To do what people want well, we’d need more features. More options. At that point, there is already the file with those needed APIs. Users can already do all they want.

We had similar behavior before in tools turning markdown -> HTML, HTML -> markdown, markdown -> roff (man pages), etc. And yanked it out, so users can be explicit.

Here’s a plugin to do it:

export default function move() {
  return function (tree, file) {
    file.extname = '.js'
  }
}

[remcohaszing]

I have my doubts about this idea too. It seems logical at first glance, but why would you emit the generated .js file next to the .mdx file? Why not save it in another directory for example? Many tools likely don’t even use the file name after processing, only the content and messages. I see why it might seem like a good idea to change the extension, but I think the use case is too specific and other solutions exist.

[altano]

Got it. So I shouldn’t think of a vfile processor like the mdx compiler as returning a new vfile representing the js?

Interestingly, when I change the path myself, I see it gets added to a history property that stores all the paths. That’s one of the reasons I thought the idea of a processor changing the path was baked into the idea of a vfile.

Thanks for considering!

[wooorm]

Yeah basically, I think it’s more apt to say that the processor takes a file and gives that file back, and when you pass a string or so, a file object is created for you. Input file -> output file. And you can do things before, or after, as you do, with the file path!