Giter Site home page Giter Site logo

staabm / phpstan-todo-by Goto Github PK

View Code? Open in Web Editor NEW
148.0 3.0 3.0 187 KB

Todo comments with expiration

Home Page: https://staabm.github.io/2023/12/17/phpstan-todo-by-published.html

License: MIT License

PHP 100.00%
comment expiration extension phpstan

phpstan-todo-by's Introduction

phpstan-todo-by: comments with expiration

PHPStan extension to check for TODO comments with expiration. Inspired by parker-codes/todo-by.

Examples

The main idea is, that comments within the source code will be turned into PHPStan errors when a condition is satisfied, e.g. a date reached, a version met, a issue tracker ticket is closed.

<?php

// TODO: 2023-12-14 This comment turns into a PHPStan error as of 14th december 2023
function doFoo() { /* ... */ }

// TODO: <1.0.0 This has to be in the first major release of this repo
function doBar() { /* ... */ }

// TODO: phpunit/phpunit:5.3 This has to be fixed when updating phpunit to 5.3.x or higher
function doFooBar() { /* ... */ }

// TODO: php:8 drop this polyfill when php 8.x is required

// TODO: APP-2137 A comment which errors when the issue tracker ticket gets resolved
function doBaz() { /* ... */ }

Supported todo formats

A todo comment can also consist of just a constraint without any text, like // @todo 2023-12-14. When a text is given after the date, this text will be picked up for the PHPStan error message.

  • the todo, TODO, tOdO keyword is case-insensitive
  • the todo keyword can be suffixed or prefixed by a @ character
  • a username might be included after the todo@
  • the comment might be mixed with : or - characters
  • multi line /* */ and /** */ comments are supported

The comment can expire by different constraints, examples are:

  • by date with format of YYYY-MM-DD matched against the reference-time
  • by a semantic version constraint matched against the projects reference-version
  • by a semantic version constraint matched against a Composer dependency (via composer.lock or virtualPackages config)
  • by ticket reference, matched against the status of a ticket (e.g. in github.com or JIRA)

see examples of different comment variants which are supported:

// todo 2023-12-14
// @todo: 2023-12-14 fix it
// @todo 2023-12-14: fix it
// todo - 2023-12-14 fix it
// todo 2023-12-14 - fix it

// TODO@staabm 2023-12-14 - fix it
// TODO@markus: 2023-12-14 - fix it

/*
 * other text
 *
 * @todo 2023-12-14 classic multi line comment
 *   more comment data
 */

// TODO: <1.0.0 This has to be in the first major release
// TODO >123.4: Must fix this or bump the version

// TODO: phpunit/phpunit:<5 This has to be fixed before updating to phpunit 5.x
// TODO@markus: phpunit/phpunit:5.3 This has to be fixed when updating phpunit to 5.3.x or higher

// TODO: APP-123 fix it when this Jira ticket is closed
// TODO: #123 fix it when this GitHub issue is closed
// TODO: some-organization/some-repo#123 change me if this GitHub pull request is closed

Configuration

Non-ignorable errors

Errors emitted by the extension are non-ignorable by default, so they cannot accidentally be put into the baseline. You can change this behaviour with a configuration option within your phpstan.neon:

parameters:
    todo_by:
        nonIgnorable: false # default is true

Reference time

By default date-todo-comments are checked against todays date.

You might be interested, which comments will expire e.g. within the next 7 days, which can be configured with the referenceTime option. You need to configure a date parsable by strtotime.

parameters:
    todo_by:
        # any strtotime() compatible string
        referenceTime: "now+7days"

It can be especially handy to use a env variable for it, so you can pass the reference date e.g. via the CLI:

parameters:
    todo_by:
        referenceTime: %env.TODOBY_REF_TIME%

TODOBY_REF_TIME="now+7days" vendor/bin/phpstan analyze

Reference version

By default version-todo-comments are checked against "nextMajor" version. It is determined by fetching the latest local available git tag and incrementing the major version number.

The behaviour can be configured with the referenceVersion option. Possible values are "nextMajor", "nextMinor", "nextPatch" - which will be computed based on the latest local git tag - or any other version string like "1.2.3".

parameters:
    todo_by:
        # "nextMajor", "nextMinor", "nextPatch" or a version string like "1.2.3"
        referenceVersion: "nextMinor"

As shown in the "Reference time"-paragraph above, you might even use a env variable instead.

Note

The reference version is not applied to package-version-todo-comments which are matched against composer.lock instead.

Prerequisite

Make sure tags are available within your git clone, e.g. by running git fetch --tags origin - otherwise you are likely running into a 'Could not determine latest git tag' error.

In a GitHub Action this can be done like this:

    -   name: Checkout
        uses: actions/checkout@v4

    -   name: Get tags
        run: git fetch --tags origin

Multiple GIT repository support

By default the latest git tag to calculate the reference version is fetched once for all files beeing analyzed.

This behaviour can be configured with the singleGitRepo option.

In case you are using git submodules, or the analyzed codebase consists of multiple git repositories, set the singleGitRepo option to false which resolves the reference version for each directory beeing analyzed.

Virtual packages

Within the PHPStan config file you can define additional packages, to match against package-version-todo-comments.

parameters:
    todo_by:
        virtualPackages:
            'staabm/mypackage': '2.1.0'
            'staabm/my-api': '3.1.0'

Reference these virtual packages like any other package in your todo-comments:

// TODO staabm/mypackage:2.2.0 remove the following function once staabm/mypackage is updated to 2.2.0

Issue tracker key support

Optionally you can configure this extension to analyze your comments with issue tracker ticket keys. The extension fetches issue tracker API for issue status. If the remote issue is resolved, the comment will be reported.

Currently, Jira, GitHub and YouTrack are supported.

This feature is disabled by default. To enable it, you must set ticket.enabled parameter to true. You also need to set these parameters:

parameters:
    todo_by:
        ticket:
            enabled: true

            # one of: jira, github (case-sensitive)
            tracker: jira

            # a case-sensitive list of status names.
            # only tickets having any of these statuses are considered resolved.
            # supported trackers: jira. Other trackers ignore this parameter.
            resolvedStatuses:
                - Done
                - Resolved
                - Declined

            # if your ticket key is FOO-12345, then this value should be ["FOO"].
            # multiple key prefixes are allowed, e.g. ["FOO", "APP"].
            # only comments with keys containing this prefix will be analyzed.
            # supported trackers: jira, youtrack. Other trackers ignore this parameter.
            keyPrefixes:
                - FOO

            jira:
                # e.g. https://your-company.atlassian.net
                server: https://acme.atlassian.net

                # see below for possible formats.
                # if this value is empty, credentials file will be used instead.
                credentials: %env.JIRA_TOKEN%

                # path to a file containing Jira credentials.
                # see below for possible formats.
                # if credentials parameter is not empty, it will be used instead of this file.
                # this file must not be committed into the repository!
                credentialsFilePath: .secrets/jira-credentials.txt

            github:
                # The account owner of referenced repositories.
                defaultOwner: your-name

                # The name of the repository without the .git extension.
                defaultRepo: your-repository

                # GitHub Access Token
                # if this value is empty, credentials file will be used instead.
                credentials: null

                # path to a file containing GitHub Access Token.
                # if credentials parameter is not empty, it will be used instead of this file.
                # this file must not be committed into the repository!
                credentialsFilePath: null

            youtrack:
                # e.g. https://your-company.youtrack.cloud
                server: https://acme.youtrack.cloud

                # YouTrack permanent token
                # if this value is empty, credentials file will be used instead.
                credentials: %env.YOUTRACK_TOKEN%

                # path to a file containing a YouTrack permanent token
                # if credentials parameter is not empty, it will be used instead of this file.
                # this file must not be committed into the repository!
                credentialsFilePath: .secrets/youtrack-credentials.txt

Jira Credentials

This extension uses Jira's REST API to fetch ticket's status. If your board is not public, you need to configure valid credentials. These authentication methods are supported:

We recommend you use OAuth over basic authentication, especially if you use phpstan in CI. There are multiple ways to pass your credentials to this extension. You should choose one of them - if you define both parameters, only credentials parameter is considered and the file is ignored.

Pass credentials in environment variable

Configure credentials parameter to read value from environment variable:

parameters:
    todo_by:
        ticket:
            jira:
                credentials: %env.JIRA_TOKEN%

Depending on chosen authentication method its content should be:

  • Access Token for token based authentication, e.g. JIRA_TOKEN=ATATT3xFfGF0Gv_pLFSsunmigz8wq5Y0wkogoTMgxDFHyR...
  • <username>:<passwordOrApiKey> for basic authentication, e.g. [email protected]:p@ssword
Pass credentials in text file

Create text file in your project's directory (or anywhere else on your computer) and put its path into configuration:

parameters:
    todo_by:
        ticket:
            jira:
                credentialsFilePath: path/to/file

Remember not to commit this file to repository! Depending on chosen authentication method its value should be:

  • Access Token for token based authentication, e.g. JATATT3xFfGF0Gv_pLFSsunmigz8wq5Y0wkogoTMgxDFHyR...
  • <username>:<passwordOrApiKey> for basic authentication, e.g. [email protected]:p@ssword

GitHub

Both issues and pull requests are supported. The comment will be reported if the referenced issue/PR is closed. There are multiple ways to reference GitHub issue/PR:

Only number
// TODO: #123 - fix me

If the defaultOwner is set to acme and defaultRepo is set to hello-world, the referenced issue is resolved to acme/hello-world#123.

Owner + repository name + number
// TODO: acme/hello-world#123 - fix me

Installation

To use this extension, require it in Composer:

composer require --dev staabm/phpstan-todo-by

If you also install phpstan/extension-installer then you're all set!

Manual installation

If you don't want to use phpstan/extension-installer, include extension.neon in your project's PHPStan config:

includes:
    - vendor/staabm/phpstan-todo-by/extension.neon

FAQ

Unexpected '"php" version requirement ">=XXX" satisfied' error

If you get this errors too early, it might be caused by wrong version constraints in your composer.json file. A php version constraint of e.g. ^7.4 means >=7.4.0 && <= 7.999999.99999, which means comments like // TODO >7.5 will emit an error.

For the php declaration, it is recommended to use a version constraint with a fixed upper bound, e.g. 7.4.* or ^7 || <8.3.

'Could not determine latest git tag' error

This error is thrown, when no git tags are available within your git clone. Fetch git tags, as described in the "Reference version"-chapter above.

๐Ÿ’Œ Give back some love

Consider supporting the project, so we can make this tool even better even faster for everyone.

phpstan-todo-by's People

Contributors

clxmstaab avatar dannyvdsluijs avatar emilmassey avatar m29corey avatar staabm avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

phpstan-todo-by's Issues

DX: Define error identifiers

In phpstan 1.11 error identifiers will be available for use to ignore specific errors. We can already use PHPStan\Rules\RuleErrorBuilder::identifier() to define custom identifiers for errors reported by this extension. They will be useful when 1.11 is released.

I think it would be a nice feature to have. If we want to have it, we should discuss what the identifiers should look like, eg. todo_by.date, todo_by.ticket, etc.

by a semantic version constraint matched against a Composer dependency not working

The "by a semantic version constraint matched against a Composer dependency" approach does not work. We receive the following output:

 ------ ---------------------------------------------------------
  Line   packages/site_codappix/ext_localconf.php
 ------ ---------------------------------------------------------
  10     Package "typo3/cms-core" is not installed via Composer.
 ------ ---------------------------------------------------------

I tried to debug via xdebug and it looks like the !InstalledVersions::isInstalled call is heading to phpstan phar version and its own packages composer dependencies instead of the actual project dependencies.

expire by version

if the extension is running in a app which is git versioned, we may be able to find out, what the current and next version is, and therefore allow a variation of the rule, which invalidates comments by a version number instead of a date

Sometimes you just do workarounds until the next minor/major version is released with some needed changes.

needs a POC

similar to the todo_while macro in https://github.com/parker-codes/todo_by

Idea: Support Symfony's deprecation-contracts

Hey Markus,

Nice extension! I'm not sure if I'll ever need it but the first thing that came to my mind when I read about the version support, was support for Symfony's trigger_deprecation() which basically also consists of a package name and a version. So devs wouldn't even need to check the deprecations anymore, your extension would already detect it during static analysis ๐Ÿ˜‰

Anyway - just an idea and I thought I'd leave it here.

Happy Holidays!

TodoByVersionRule should not match date comments

the pattern in TodoByVersionRule is not optimal, which means the rule will trigger on the following example

<?php
//  TODO: 2022-12-08 Foo

only the TodoByDateRule should be triggered in this case.

Idea: todo expire todo when PR is released

Hi!

not sure you'll like this one, as it is a logic suite of #31, but going a little bit further ๐Ÿ˜…

Something I'd find really useful would be to expire todo comments based on a vendor PR link: when the PR is merged and released, and vendor meets the release version in your dependencies.

I've seen a lot of projects cluttered with comments like this:

// todo: remove this workaround when https://github/vendor/lib/pull/1234 is released

and these todos are only fixed if by chance someone some day sees the comment and gives it some attention.

GitHub exposes in its api the first release when a PR appears. So, I think it could leverage the work done in #32

WDYT?

Set level by env

Good idea this extension!

It's possible to set level alert by environment?
For example, to be free to decide to trigger just a warning in dev mode, test mode, but error prod mode.

The goal is to configure github actions/gitlab CI to just set a warning when push commit but block merged in main if error is triggered.

support full github issue urls

I think we should support comments with a full github url:

// TODO: https://github.com/staabm/phpstan-todo-by/issues/91 we need todo something when this issue is resolved

I think these are helpful, because the urls represent a ticket uniquely.


in contrast, comments like

// TODO: some-organization/some-repo#123 change me if this GitHub pull request is closed

have the problem, that you need to know how phpstan-todo-by is configured, to reason what the correct url for this relative identifier is.


I think we should even detect/verify these full url todos when the issue tracker is not configured to be github.
my guess is that github.com urls would be the lions share of urls used in comments.

the only other public issue tracker which might be similar widely used is gitlab.com.

turned differently: IMO when a todo comment is followed by a full url, we should work against a whitelist of default providers (no matter what is configured to be "the default issue tracker" in the config file.)

TodoByPackageVersionRule: backtrack limit error

the comment

// TODO: minimumApiClientVersion:2.0 This can be removed once all API consumers use client version 2.0 or higher

Uncaught RuntimeException: Error in PCRE: Backtrack limit exhausted in /Users/staabm/workspace/phpstan-todo-by/src/utils/CommentMatcher.php:43
#0 /Users/staabm/workspace/phpstan-todo-by/src/TodoByPackageVersionRule.php(71): staabm\PHPStanTodoBy\utils\CommentMatcher::matchComments(Object(PhpParser\Node\Stmt\Nop), '{\n    @?TODO # ...')
#1 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/src/Analyser/FileAnalyser.php(107): staabm\PHPStanTodoBy\TodoByPackageVersionRule->processNode(Object(PhpParser\Node\Stmt\Nop), Object(PHPStan\Analyser\MutatingScope))
#2 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/src/Analyser/NodeScopeResolver.php(459): PHPStan\Analyser\FileAnalyser->PHPStan\Analyser\{closure}(Object(PhpParser\Node\Stmt\Nop), Object(PHPStan\Analyser\MutatingScope))
#3 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/src/Analyser/NodeScopeResolver.php(402): PHPStan\Analyser\NodeScopeResolver->processStmtNode(Object(PhpParser\Node\Stmt\Nop), Object(PHPStan\Analyser\MutatingScope), Object(Closure), Object(PHPStan\Analyser\StatementContext))
#4 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/src/Analyser/NodeScopeResolver.php(641): PHPStan\Analyser\NodeScopeResolver->processStmtNodes(Object(PhpParser\Node\Stmt\Namespace_), Array, Object(PHPStan\Analyser\MutatingScope), Object(Closure), Object(PHPStan\Analyser\StatementContext))
#5 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/src/Analyser/NodeScopeResolver.php(371): PHPStan\Analyser\NodeScopeResolver->processStmtNode(Object(PhpParser\Node\Stmt\Namespace_), Object(PHPStan\Analyser\MutatingScope), Object(Closure), Object(PHPStan\Analyser\StatementContext))
#6 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/src/Analyser/FileAnalyser.php(166): PHPStan\Analyser\NodeScopeResolver->processNodes(Array, Object(PHPStan\Analyser\MutatingScope), Object(Closure))
#7 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/src/Analyser/Analyser.php(72): PHPStan\Analyser\FileAnalyser->analyseFile('/Users/staabm/w...', Array, Object(PHPStan\Rules\LazyRegistry), Object(PHPStan\Collectors\Registry), NULL)
#8 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/src/Command/AnalyserRunner.php(62): PHPStan\Analyser\Analyser->analyse(Array, Object(Closure), NULL, true, Array)
#9 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/src/Command/AnalyseApplication.php(209): PHPStan\Command\AnalyserRunner->runAnalyser(Array, Array, Object(Closure), NULL, true, true, '/Users/staabm/w...', Object(_PHPStan_39fe102d2\Symfony\Component\Console\Input\ArgvInput))
#10 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/src/Command/AnalyseApplication.php(101): PHPStan\Command\AnalyseApplication->runAnalyser(Array, Array, true, '/Users/staabm/w...', Object(PHPStan\Command\Symfony\SymfonyOutput), Object(PHPStan\Command\Symfony\SymfonyOutput), Object(_PHPStan_39fe102d2\Symfony\Component\Console\Input\ArgvInput))
#11 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/src/Command/AnalyseCommand.php(198): PHPStan\Command\AnalyseApplication->analyse(Array, true, Object(PHPStan\Command\Symfony\SymfonyOutput), Object(PHPStan\Command\Symfony\SymfonyOutput), false, true, '/Users/staabm/w...', Array, Object(_PHPStan_39fe102d2\Symfony\Component\Console\Input\ArgvInput))
#12 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/vendor/symfony/console/Command/Command.php(259): PHPStan\Command\AnalyseCommand->execute(Object(_PHPStan_39fe102d2\Symfony\Component\Console\Input\ArgvInput), Object(_PHPStan_39fe102d2\Symfony\Component\Console\Output\ConsoleOutput))
#13 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/vendor/symfony/console/Application.php(870): _PHPStan_39fe102d2\Symfony\Component\Console\Command\Command->run(Object(_PHPStan_39fe102d2\Symfony\Component\Console\Input\ArgvInput), Object(_PHPStan_39fe102d2\Symfony\Component\Console\Output\ConsoleOutput))
#14 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/vendor/symfony/console/Application.php(261): _PHPStan_39fe102d2\Symfony\Component\Console\Application->doRunCommand(Object(PHPStan\Command\AnalyseCommand), Object(_PHPStan_39fe102d2\Symfony\Component\Console\Input\ArgvInput), Object(_PHPStan_39fe102d2\Symfony\Component\Console\Output\ConsoleOutput))
#15 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/vendor/symfony/console/Application.php(157): _PHPStan_39fe102d2\Symfony\Component\Console\Application->doRun(Object(_PHPStan_39fe102d2\Symfony\Component\Console\Input\ArgvInput), Object(_PHPStan_39fe102d2\Symfony\Component\Console\Output\ConsoleOutput))
#16 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/bin/phpstan(124): _PHPStan_39fe102d2\Symfony\Component\Console\Application->run()
#17 phar:///Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan.phar/bin/phpstan(125): _PHPStan_39fe102d2\{closure}()
#18 /Users/staabm/workspace/phpstan-todo-by/vendor/phpstan/phpstan/phpstan(8): require('phar:///Users/s...')
#19 /Users/staabm/workspace/phpstan-todo-by/vendor/bin/phpstan(119): include('/Users/staabm/w...')
#20 {main}

triggers a PCRE backtrack limit error

non-ingorable config switch

consider adding a config switch which turns errors reported by the rule to be non-ignorable.

that would help against accidental baselining

UX-wise it might make sense to add a error-tip when errors are not ignorable which hints configuration option

Get an error for a TODO without an expiration constraint

Hello, great package!

I may have not searched correctly, but is there a way to get PhpStan fail with an error if a TODO exists without an expiration constraint?

For instance, if I write:

// TODO: write tests

I'd like to configure phpstan-todo-by in a way it will reject my TODO until I set a condition.

Is it possible?

BC Break: re-organize config file

Atm most config settings are at the top level of parameters.todo_by.

Since we got more and more rules, we should restructure that a bit.

Expire comment by config value

I am not sure if using config values is the best way to achieve this, but I have the following uses cases where something like this would be very helpful:

  • We provide an application that is run and updated by third-parties. That software has certain code paths that need to run at least once, e.g. database migrations. Code paths can be removed once run everywhere.
  • We provide an API that has compatibility layers for older client versions. Once support is removed for those older versions, the compatibility layers can be removed too.
  • We integrate with self-hosted instances of various third-party APIs and have code paths to support older versions where certain API endpoints are missing or return data in a different format. We would like to remove those code branches once all instances have been upgraded.

I was thinking about a section in the PHPStan config like:

parameters:
    todo_by:
        values: # or something more helpful
            minimumApiClientVersion: 1.2

and then near the code path

// TODO: minimumApiClientVersion:2 This can be removed once all API consumers use client version 2.0 or higher

UX: better readable date format

consider using a more human readable date format, e.g. with month as a written word

// TODO: 2023 December 14 Expired comment1

goal: make it clear which part of the date is the day and which is the month


the dateformat implemented initially is the one used by the projects which this extension got inspiration from.
we might support both formats. we should stay compatible with the inspiring repos.

we need to check whether adding more formats has a perf impact

multi git repo setup

when analysing a codebase in which separate folders are git clones of different repositories, it might make more sense to fetch the reference version based on the current file beeing analysed like

git -C redaxo/src/addons/rexstan for-each-ref --sort=-creatordate --count 1 --format="%(refname:short)" "refs/tags/"

this would be slower, as we have to lookup the git tag per file which contains a version comment, but it might be necessary/more correct.

maybe it makes sense to have it as a configuration switch


atm the git tag is detected relative to the current working directory of the phpstan process

Improve Expiration Date recognition

Hi

I was playing around with it, and figured out that the expiration date has to be in a strict format
with 2-digit months

if people do not pay attention to that, then NO error is being displayed, which is risky

throws error - OK

// TODO: 2023-01-22 This comment turns into a PHPStan error as of 22nd december 2023

should throw error but does not - NOT OK

// TODO: 2023-1-22 This comment turns into a PHPStan error as of 22nd december 2023

maybe this could be improved :)

thanks for this great extension

http caching

we should have a http cache builtin, to reduce the impact of http requests on the phpstan analysis process.
I think we just need to cache a url to ticket status mapping.

this will also make sure we won't hammer the APIs of the issue trackers from all todo-by users.

  • as soon as a new comment key is discovered the whole cache should be expired. that way people trying phpstan-todo-by for the first time get nearly non-cached responses all the time
  • the cache should have a short default expiration, maybe 1 hour?
  • the cache life time should be configurable via .neon
  • it should be possible to disable the cache via .neon config
  • the cache should be stored in the phpstan temp folder in a single file

Suggestions

Few things that I suggest:

  1. Make the code case-insensitive. This would include changing the pattern by adding an "i" after the closing slash, and change other string comparison sections to make the subject match case of the comparison.
  2. Add an optional "@" to the start of the pattern.
    I preface my todo comments with "@" for IDE highlighting reasons.
  3. Use named capture groups in the regular expression:
    '/^TODO:?\s*(?P<date>[0-9]{4}-[0-9]{2}-[0-9]{2}):?(?P<comment>.*)$/'
    You can then reference these names rather than integer indexes in the $matches array.
    Details about it can be found here: https://www.php.net/manual/en/regexp.reference.subpatterns.php
  4. Make your variable interpolation consistent.

expire comment by composer package version

the idea is to expire a comment when a composer dependency is updated to a certain version, because you e.g. might wanne to cleanup some hacks which are currently required but are not longer after updates of said dependency.

a possible syntax could be similar to the version constraint one, but just with an additional composer package name prefixed

// TODO: phpunit/phpunit:<10 This has to be fixed when updating to phpunit 10.x

see phpstan/phpstan#9056


needs a POC and I am not sure yet, whether I like it.

Respect configurable vendor folder location

This can be seem as follow up to #54 (comment)

We now have a project where best practices define to move the vendor folder. This is pretty common for TYPO3 Extension. You can find the repository here: https://github.com/FriendsOfTYPO3/tea it serves as a best practice for the community and we want to add the to do extension.

But that doesn't work due to the different vendor location. It therefore would be cool if the extension would read the location and that way support the actual path.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.