console-helpers / code-insight Goto Github PK

Right now bc command accepts these arguments/options:

• source path (required)
• source fork (default: empty)
• target path (default: current project)
• target fork (default: empty)

Such defaults work perfectly, when a need arises to compare 2 working copies, but doesn't work, when a need arises to compare project with it's own version in past.

Proposing to:

1. make either source path or source fork required
2. when source path is missing, but source fork is specified, then use target path as source path

The command will show deprecated code elements (properties, classes, methods) introduced in new version in comparison to old version.

The bc command only reports technical (by definition) BC breaks, which in some cases:

• can be a false positive (e.g. parameter of method renamed for clarity)
• can be intended change (e.g. scope reduced)

Once #11 is implemented the BC break definition can be exported as JSON. This in turn can be used to define bc break ignore rules via bc_ignore setting in .code-inside.json file.

This way all handled BC breaks can be marked in there and no longer be reported on next run.

An optional reference parameter can be defined with each ignore telling why this was ignored in first place.

In readme.md, it writes

download latest released PHAR file from https://github.com/console-helpers/code-insight/releases page.

However, there is nothing in https://github.com/console-helpers/code-insight/releases. Is it possible to publish a release? Thanks!

Right now Travis CI build fails on PHP 7.x because PHPUnit version used there doesn't know non-namespaced classes anymore.

E.g. https://travis-ci.org/console-helpers/code-insight/jobs/286920603

Need to write usage guide in README.md

For single-class analysis the PHP_CodeSniffer is the best tool to use. However it can't do cross-class analysis.

Things to check:

1. no E_STRICT violations (ensure, that sub-class method signature is substr of all parent classes method signature)

When class was final and stayed final then it's protected members (e.g. properties or methods) should be considered as private in terms of BC checks, e.g.:

• ignore scope reduction (from protected to private)
• ignore signature change of protected methods

When property/method becomes static or looses static status it should trigger BC break because:

1. accessing non-static property/method in a static way would trigger a notice
2. accessing static property/method in a non-static way is just bad practice

Right now the bc command always prints human readable report. Proposing to:

1. during bc break collection store them in some kind of data structure instead of printing back to user
2. via --format option allow exporting bc breaks as: text, html, json

The In-Portal class BC checker detects new style tags (e.g. function TagName(array $params)) but doesn't detect old style tags (e.g. function TagName($params)).

The tag in In-Portal is considered any method, that:

• is located within *TagProcessor class
• name starts with uppercase letter
• has single parameter named $params

Turns out that method name isn't checked and prepareTagParams($params) also is detected as tag.

Don't consider added optional parameter as bc break.

Currently to run cross-version commands the 2 working copies needs to exist in parallel and each have:

• code-inside.sqlite database
• .code-inside.json config file

This becomes a problem when there is only 1 working copy and comparison needs to be made between 2 commits (e.g. current and previous) in it. In that case the .code-inside.json file is committed, but code-inside.sqlite file isn't.

Implementation ideas:

• store code-inside.sqlite not next to .code-inside.json file in the project folder, but inside ~/.code-insight/xxx folder where xxx is absolute path to folder containing .code-inside.json file
• add --fork name option to sync command, that will instruct all changes to be made on db copy under given name
• allow for bc and cs commands to have source-path and target-path paths to allow forks, when new --source-fork and --target-fork options are specified