Project build

A little recap, grunt is old and slower compared to webpack so I proposed to migrate to it. This is the build setup using webpack, I've also added the browser field to package.json file pointing to the unminified build for the web projects, it's not ready yet to fully replace grunt we must move the documentation generator also... I've tried also to replicate the grunt-documentation plugin using the documentation npm module but the output is quite different and I don't understand why since the options are the same, probably it's because I'm using a newer version.

Project documentation

TL;DR DEMO

This is the file I've made for programmatical use of documentationjs, but the output is somehow different :( probably depends of the newer version, but I don't know exactly.

I've created another branch to try out jsdoc with this project and managed to make it work after fixing a couple of tags errors, there are still some checks to do, regards examples and other parts of the documentation to ensure they match the jsdoc standard... but this is a preview of the result.

This is the default theme, if you like this solution we can use the theme you like more.

I think in terms of readability and usability is better than the wiki pages, I admit I'm used to read stuff in github, I spend most of my time on it, but since jsdoc (esdoc, tsdoc and friends) are widely used I feel familiar to move around the documentation generated by that tools.

The idea is to migrate the documentation, merge it in the webpack branch and than merge back into v3.1. What do you think about it?

Related to #189 issue, the parser should be able to extract comments on trailingComments in order to better represent their position on the document.

Sample use case : https://astexplorer.net/#/gist/2674d53a98c68e273b96adaa99047e61/5c6bbdbfad0d9996203e56dcfae8659ec593fc57

Input:

$var = "string ${juices['FOO']} string";

Encapsedpart node contains variable node, but should contains offsetlookup node.

PHP parser output:

array(
    0: Stmt_Expression(
        expr: Expr_Assign(
            var: Expr_Variable(
                name: var
            )
            expr: Scalar_Encapsed(
                parts: array(
                    0: Scalar_EncapsedStringPart(
                        value: string 
                    )
                    1: Expr_ArrayDimFetch(
                        var: Expr_Variable(
                            name: juices
                        )
                        dim: Scalar_String(
                            value: FOO
                        )
                    )
                    2: Scalar_EncapsedStringPart(
                        value:  string
                    )
                )
            )
        )
    )
)

Expr_ArrayDimFetch is same as offsetlookup

Maybe will be great add tests for propertylookup and staticlookup to ensure ast correct for lookup nodes.

Builds on #724 lexer functionality.

PHP 8 Attribute Features:

• [x] Class
• [x] Methods
• [x] Method Params
• [x] Class Variables
• [x] Inline Functions fn()..
• [x] Functions
• [x] Anonymous Classes
• [x] Class Constants
• [x] Interfaces

Input:

list(,$first, $second, $three, $fourth,) = $arr;

Contain null in arguments.

Babylon example: https://astexplorer.net/#/gist/6d37953c6b42f02a3ffe48b6101127c3/745b62f49d2c011d789e6d9754a4d705db5cdab0

I think it is unnecessary, because it is doesn't have sense for executing/parsing/printing/etc.

Input:

$var = $var + $var ?? '';

Input:

function gen() {
  yield 0;
  yield from from();
  yield 4;
}

I honestly can’t understand what the problem is, why you can not devote a little more time to tests and details, what is the problem of being more responsible for the project or asking for help (hi, i am here and can test branches before merge :hand: )?

Each update is pain and regressions :disappointed:

I understand that we all have work here and a little time, but what is the problem to wait for the review and feedback before merge?

Currently, a typical test looks roughly like this:

  it("test coalesce operator", function() {
    var ast = parser.parseEval("$var = $a ?? true;");
    ast.children[0].right.kind.should.be.exactly("bin");
    ast.children[0].right.type.should.be.exactly("??");
    ast.children[0].right.left.kind.should.be.exactly("variable");
    ast.children[0].right.right.kind.should.be.exactly("boolean");
});

After working with snapshot-based testing for a while in prettier/plugin-php, I've really come to appreciate not having to write my own assertions anymore.

If we were to introduce snapshot-based testing here, the test case above would essentialy boil down to just one line, which could even be stored in a .php file:

$var = $a ?? true;

The testing framework would then generate the snapshot and save it in a file:

{
  "kind": "program",
  "children": [
    {
      "kind": "assign",
      "operator": "=",
      "left": {
        "kind": "variable",
        "name": "var",
        "byref": false,
        "curly": false
      },
      "right": {
        "kind": "bin",
        "type": "??",
        "left": {
          "kind": "variable",
          "name": "a",
          "byref": false,
          "curly": false
        },
        "right": {
          "kind": "boolean",
          "value": true,
          "raw": "true"
        }
      }
    }
  ],
  "errors": []
}

Like this, we'd see the exact AST changes that every PR introduces to any of the existing test cases.

It seems that Esprima is using a similar approach.

If you're interested, I could try preparing a little proof of concept - let me know what you think! 😄

So I have some code: echo "test: $this->prop->foo".

When trying to parse this code, the parser crashes without an error, however adding { } around the property call resolves the issue and it parses successfully.

So echo "test: {$this->prop->foo}" works.

Even if this behaviour is not allowed in PHP, the parser should throw an exception so it can be caught on the user side. Currently this code crashes my application without warning, regardless if I use a try/catch block or not.

Great job with this module, It's almost perfect but the parseCode method is skipping the comment. We would like to use the parser to decompose and rewrite our php class (in order to enrich them), but, it's actually impossible to rewrite without the comments (for obvious reason). Is it possible to add this feature to your module? Regards.

Example

$this->foo::bar;

I don't see any rfc or documentation for this feature but it does work in php 7.0, iv been using it in production for quit a while.

• [x] Trailing Commas In List Syntax : https://wiki.php.net/rfc/list-syntax-trailing-commas
• [x] Object typehint : https://wiki.php.net/rfc/object-typehint
• [x] Short list syntax : https://wiki.php.net/rfc/short_list_syntax

Bumps husky from 8.0.2 to 8.0.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

atm checking https://php-parser.glayzzle.com/guides/options doesnt show all the available options/config ex.php7 which am not sure if its even needed anymore.

or whats the diff between this two

parser: {
    locations: true,
},
ast: {
    withPositions: true
}

Is this approach ok?

According to https://php.watch/versions/8.2/readonly-classes

Abstract classes final classes can also be declared readonly. The order of the keywords does not make a difference.

I know some tests will fail, I am showing this to verify that my approach is ok.

Bumps webpack-cli from 4.10.0 to 5.0.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I encountered the following source discrepancies while moving my AST->PHP writer from any types to strict typing. They are tolerable in JavaScript but cause problems in a type safe TypeScript:

• continue and break aren't consistent in their level, one uses a plain number while the other a Number extended from Node.
• empty extends Expression and uses an expression property but it isn't actually defined as such (empty.js fails to mention the property, consequently, it isn't generated into types.d.ts).
• isset is the same with the variables property,
• print is the same with the expression property,
• unset is the same with the variables property.
• namedargument is lowercase, all other node types have PascalCase names.
• String normally contains the whole string, with the appropriate quotes, as dictated by isDoubleQuote. However, EncapsedPart can also contain a String fragment and that has no quotes of its own. Although I can work around this, the perfectly correct solution would require either an isQuoted property for String or a new node type like EncapsedString to be used just here.
• Repeated case labels are stored rather problematically, they are empty Case branches with no relation to the actual branch they belong to. They should be consolidated into a single Case instead, with a test property of Expression[] instead of a single expression.
• Property and Constant both are supposed to have a name of simple type string. In reality, they receive an Identifier.
• UseGroup defines an item property but actually populates one named items.
• The type field of Function can be null, too.

And something not actually an error but a very needed, very small addition: Node should have a parent property and it should be populated when the AST is generated. It's of paramount importance for any tree manipulation. I can also work around this by using my additional union type and populating it during my own traversal but it would be a very cheap addition to the core.

Was the AST ever intended to be modified externally? I've just written an AST->PHP writer (yes, I'm aware of php-writer, it's very old and dated, I needed the full support up to the latest PHP 8.1). It's in TypeScript, actually, not JavaScript. I didn't yet have time to test it at all but I'm more than willing to share it as soon as it's reasonably error free.

However, this leads to the current question. I'd need to modify the AST so that I can export it in full or partly back to PHP. Was php-parser ever intended to support this scenario? The various AST classes don't seem to have constructors and there seems to be no easy way to build or modify an AST tree (except for assembling PHP strings and parsing them eval-style but that's not what would really be needed).