Input:
if (true) {
$a = 1;
}
// Don't parsed :(
if (false) {
$a = 2;
}
It's voluntary because I need to handle else or elseif nodes (check here from the code) :
https://github.com/glayzzle/php-parser/blob/master/src/parser/if.js#L44
I'm wondering if getting the AST as input for your transformation is not the wrong approach. How comments are handled into JS parser ?
For me, the doc nodes should not be present in the AST as long as they do not belongs to the instructions sets. You can read this old issue here for more details : https://github.com/glayzzle/php-parser/issues/6
If think for this special case as the comment is not between an if and an else statement I can handle it, but this case will never work :
if(true) {
// ... ok
}
// some explanation (missing)
else {
// ... ok
}
The best approach would be to extract documentation node into another property like comments, like done by babylon or flow in JS :

I've introduced the extractAllDocs option :
<?php $a = 1 + /* Hello */ 2;
Becomes :
Program {
kind: 'program',
children: [ Assign { kind: 'assign', operator: '=', left: [Object], right: [Object] } ],
errors: [],
comments: [ Doc { kind: 'doc', isDoc: false, lines: [Object] } ] }
But in order to be consistent in principle I should put every comment inside this array and strictly avoid to use them ouside this array. It's also related on an old issue : https://github.com/glayzzle/php-parser/issues/62
@ichiriac we implement logic as js prettier based on babylon. He have also comments (https://astexplorer.net/#/gist/3202ee068c3e3f3645588357d931216f/14a080841262821fa733893886d8fc99ac711795) and it is good :+1:
@nevadascout, @rasmusbe, can you please give me your point of view on this major change on the next release ?
In the next release, I can provide a structure more close to babylon parser with an leadingComments array :

Would this be a breaking change?
Hi @nevadascout, glad to hear you
Yes this will be a breaking change, but it only concerns the doc nodes. I plan stop using then into children lists or bodies, and attach them directly to nodes by using a leadingComments property.
In fact if you are actually ignoring doc nodes there is no problem, and if you use them to document functions or variable, with this approach it will be simpler (but needs you to update a bit your code)
Sounds good, thanks!
Hi @evilebottnawi,
It's implemented and tackles your comment issues:
PHP Script :
<?php
// foo class
class foo {
/* const bar */
const bar = 1;
}
AST Structure :
{
"kind": "program",
"children": [
{
"kind": "class",
"leadingComments": [
{
"kind": "commentline",
"value": "// foo class\n"
}
],
"name": "foo",
"isAnonymous": false,
"extends": null,
"implements": null,
"body": [
{
"kind": "classconstant",
"leadingComments": [
{
"kind": "commentblock",
"value": "/* const bar */"
}
],
"name": "bar",
"value": {
"kind": "number",
"value": "1"
},
"isAbstract": false,
"isFinal": false,
"visibility": "",
"isStatic": false
}
],
"isAbstract": false,
"isFinal": false
}
],
"errors": [],
"comments": [
{
"kind": "commentline",
"value": "// foo class\n"
},
{
"kind": "commentblock",
"value": "/* const bar */"
}
]
}
The v3.0.0 is not yet ready, remains other fixes, but meanwhile you can use the master branch for testing, and the https://glayzzle.com/php-parser uses already latest master version.
Hi, I think this is a great improvement, trying it right now.
I've made all changes in wp-pot needed for php-parser 3.0, and it works great with the separate comments array. 馃帀
Most helpful comment
@nevadascout, @rasmusbe, can you please give me your point of view on this major change on the next release ?
In the next release, I can provide a structure more close to
babylonparser with anleadingCommentsarray :