I have one more concern, if this get merged, the print can't be async. But some plugins call parse in print, and we already allow parse to be async, so the plugin will be broken. I guess the answer is move those parts to embed?

@prettier/plugin-pug format embed languages in this way.

//cc @Shinigami92

I can't see where it calls parse in print

https://github.com/prettier/plugin-pug/blob/6ed005ec74e3ac2eb1a48699802b3f574f57998b/src/printer.ts#L650

I guess that should be moved to embed then. Isn't this what embed is for?

As mentioned reason here, thorn0#1 (comment), this plugin has to move it to embed and add a fallback in print.

@Shinigami92 ^

Any comment?

@Shinigami92 ^

Any comment?

Would make things much harder for me (I wrote the whole plugin in an iterative way instead of a AST walker because pug works much better and more performant this way)
But yeah, as this breaking change introduced by prettier I would assume a major version bump
and then I and other plugin maintainers need to deal with the breaking change 🤷

As I understand, you don't use print either, you traverse AST yourself?

In that case, you can also do print (async stuff) in parse... Some other plugins do this..

@Shinigami92 Making printer.print async lead to a 20% slowdown. See #13158 (comment)

I get the tokens in parse: https://github.com/prettier/plugin-pug/blob/6ed005ec74e3ac2eb1a48699802b3f574f57998b/src/index.ts#L69-L71
Pass it to print https://github.com/prettier/plugin-pug/blob/6ed005ec74e3ac2eb1a48699802b3f574f57998b/src/index.ts#L105-L107
And process it with a while-loop in the Printer: https://github.com/prettier/plugin-pug/blob/6ed005ec74e3ac2eb1a48699802b3f574f57998b/src/printer.ts#L325

@fisker print can be allowed to be async if it's not used recursively (await only the root call), but that would be a really clumsy API. We might want to keep it undocumented.

We also have printer.preprocess() maybe should allow it to be async?

Will you try this?

No, I really doubt it'll do a better job than ignoredProperties already does.

How about moving printer.massageAstNode.ignoredProperties to printer.ignoredProperties? It also should be used in other places where the AST in traversed (e.g., hasNode).

If we are going to do this, I prefer

getVistorKeys(node) {}

Before we implement the real vistor keys, we can just simply use

const ignored = new Set(['tokens'])
getVistorKeys(node) {
	return Object.keys(node).filter(key => !ignored.has(key))
}

That doesn't look performance-friendly. It will need to be called for each node: a function call, creating an array of keys, and iterating it. A simple set.has check must be much cheaper.

a function call, creating an array of keys, and iterating it.

When traverse ast, normally you need "get keys/values", "check keys", " iterating it", aren't they the same?

Yep. Somehow I misread what you're proposing. It might be not that bad.

But why do you think a simple ignored set won't be good enough? Do you have any specific cases in mind?

Not really, just every estree traver I used use vistorKeys, maybe we can check what the reason behind it.

acorn add walk for each ast type from beginning, acornjs/acorn@b660ff6, I guess to be more effective?

Probably. Also maybe it's important to visit keys in a specific order.

Many parsers come with traverse function, eg https://github.com/graphql/graphql-js/blob/67aefd9c1daefceacf937363c2da9e1117e550d9/src/language/visitor.ts#L177, if we remove AstPath someday, we may want use this function or vistorKeys.

How are we going to know where we are at the tree without the path?
(Side question: do the tests pass locally for the next branch for you? I get 18 failed, seems to be related to color codes.)

Link to that I ask meriyah to supply such ithing meriyah/meriyah#180

I get 18 failed, seems to be related to color code

I found it few hours ago , was working on it, but late here. Caused by #13208. I changed cli test to not print color by default, but not working.

Ah, okay. I'm glad that it's not something local with my env.
And another question: https://github.com/prettier/prettier/pull/13211/files#diff-f825b86383b78b8c50baa02327cfd46f6c1a3fee472409d978e5454672a83417R13
Is it expected that plugins persist across format calls? Looks like a bug to me.

How are we going to know where we are at the tree without the path?

Eslint use .parent #10785

Is it expected that plugins persist across format calls?

Not sure.

Maybe what I occurred in #13201 is related, but I forgot what the possible bug is, this "Revert plugin change to avoid possible bug" commit fixed test.

Is it expected that plugins persist across format calls?

Tracked it down: #13235