Closed elmasse closed 3 years ago
Hi! It seems you removed the template which we require. Here are our templates (pick the one you want to use and click *raw* to see its source):
I won’t send you any further notifications about this, but I’ll keep on updating this comment, and hide it when done!
Thanks, — bb
I am guessing this is because this utility expects a modern VFile (which uses .value
), whereas remark/rehype/unified are still using the previous vfile (.contents
). All of vfile/syntax-tree/micromark/wooorm has been updated, but unified/remark/rehype have not.
Here is a minimal example that shows this utility working:
import parse5 from 'parse5'
import {VFile} from 'vfile'
import {fromParse5} from 'hast-util-from-parse5'
import {inspect} from 'unist-util-inspect'
import {raw} from './index.js'
const file = new VFile('<h1>whatever</h1>')
const p5ast = parse5.parse(String(file), {sourceCodeLocationInfo: true})
const tree = fromParse5(p5ast, file)
console.log('1', inspect(tree))
raw(tree, file)
console.log('2', inspect(tree))
Yields:
1 root[1] (1:1-1:18, 0-17)
│ data: {"quirksMode":true}
└─0 element<html>[2]
│ properties: {}
├─0 element<head>[0]
│ properties: {}
└─1 element<body>[1]
│ properties: {}
└─0 element<h1>[1] (1:1-1:18, 0-17)
│ properties: {}
└─0 text "whatever" (1:5-1:13, 4-12)
root[1] (1:1-1:18, 0-17)
│ data: {"quirksMode":true}
└─0 element<html>[2]
│ properties: {}
├─0 element<head>[0]
│ properties: {}
└─1 element<body>[1]
│ properties: {}
└─0 element<h1>[1] (1:1-1:18, 0-17)
│ properties: {}
└─0 text "whatever" (1:5-1:13, 4-12)
Hi! Thanks for taking the time to contribute! This has been marked by a maintainer as needing a reproduction: It’s not yet clear whether this is a problem. Here are a couple tips:
Thanks, — bb
@wooorm thanks for your promptly reply.
However, my intention with this issue might be unrelated to having a vFile. In the integration test case there is no vFile involved, that's why I reproduced the exact same scenario failing.
In my case, I have tested this in https://github.com/elmasse/nextein project using just remark/rehype which uses not the v7 but a previous v6 of hast-util-raw causing the same issue.
On the other hand, I have inspected the vFile passed by my unified processor and makes no difference since is just an empty holder.
My problem arises when I tried to keep up to date with my dependencies and updating to rehype-raw@5.1.0 breaks and, as far as I can tell, it seems to be related to this module.
Let me know if I can provide more information. I could fork and create a test case in any of the repos.
Thanks
Max
So in rehype-raw@5 it worked, and in v5.1 it stopped?
On the other hand, I have inspected the vFile passed by my unified processor and makes no difference since is just an empty holder.
Do you mean the vfile
you pass is empty? As in, you don’t pass the source contents/value of the file in at all?
So in rehype-raw@5 it worked, and in v5.1 it stopped?
It stopped in v5, I had to downgrade to v4 (which is what I was using before). Honestly I haven't tested v5 vs v5.1 since I did an update by npm ranges.
Do you mean the vfile you pass is empty? As in, you don’t pass the source contents/value of the file in at all?
As I stated in the test case, I use a plain string that I pass to processor.parse
. I guess I could try to use to-vfile but in any case, since the parser generates the tree with position information, I don't quite understand why the raw will remove them.
since the parser generates the tree with position information, I don't quite understand why the raw will remove them.
The problem is that, yes, the parser has the source file so it can add positional info, but this plugin also needs the source file. The solution thus is to also pass the source to run
: https://github.com/unifiedjs/unified#processorrunsyncnode-file.
I don’t see how this ever worked on v4 though? The difference between 4 and 5 was added types 🤔
could you confirm whether:
const doc = 'whatever'
process.runSync(process.parse(doc), doc)
Does the trick?
Yes, that works!
Awesome, thanks!
Closing this issue.
Hi! This was closed. Team: If this was fixed, please add phase/solved
. Otherwise, please add one of the no/*
labels.
Hi team! I don’t know what’s up as there’s no phase label. Please add one so I know where it’s at.
Thanks, — bb
Great to hear! ✨
Using hast-util-raw directly from this package or thru rehype-raw removes position fields when using a combination of
proc.runSync(proc.parse(text))
Initial checklist
Affected packages and versions: v6+
Steps to reproduce
Here is a failing test case using the same data from the tests suite in the repo:
Link to code example:
When using unified with remark-parse, remark-rehype and hast-util-raw (and rehyper-raw) the position is removed as noted in the next test case. I added a first check to ensure position is present after the transform to rehype.
I used the data in the current test suite to create a failing case:
Expected behavior
The position fields should not be removed.
Actual behavior
The position fields are being removed