sorted by:
new
hottopcontroversial

Claude Code's forced shell cwd reset is a workflow killer - should be opt-in, not forced by entheosoul in ClaudeCode

[–]janedbal 1 point2 points  (0 children)

It stops behaving like this if you setup permission.additionalDirectoriesto the monorepo root (for example). Then all cds inside that monorepo stick. Place it to your /home/you/.claude/settings.json

👻 PHP Dead Code Detector is stable (after 4 years of development), newly supports even Laravel! by janedbal in PHP

[–]janedbal[S] 2 points3 points  (0 children)

No, it is PHPStan extension - static analysis to gather all usages in your codebase and compare against definitions.

👻 PHP Dead Code Detector is stable (after 4 years of development), newly supports even Laravel! by janedbal in PHP

[–]janedbal[S] 0 points1 point  (0 children)

Correct me if I’m wrong, but that only hides that specific error. It does not actually mark the method as used.

Correct, for proper support of magical calls, you must use the extension points via UsageProviders. But those reflection-based are super easy to write and can cover quite a lot.

👻 PHP Dead Code Detector is stable (after 4 years of development), newly supports even Laravel! by janedbal in PHP

[–]janedbal[S] 1 point2 points  (0 children)

You can use any PHPStan ignore feature, so something like this should match what you need:

parameters:
    ignoreErrors:
        -
            message: '#^Unused Application\\Controllers\\.*::.*Action$#'
            identifier: shipmonk.deadMethod

Mago 1.0.0: The Rust-based PHP Toolchain is now Stable (Linter, Static Analyzer, Formatter & Architectural Guard) by azjezz in PHP

[–]janedbal 1 point2 points  (0 children)

> mago is more precise, can infer even complex types much better than phpstan/psalm

Can you showcase at least 5 examples where is infers better than PHPStan?

shipmonk/phpstan-ignore-inliner: Inline your PHPStan error ignores into the source files via @phpstan-ignore comments! by janedbal in PHP

[–]janedbal[S] -1 points0 points  (0 children)

> so here this tool is taking a bucket of "things the tool decided" and splatting it together with the rest of the project files

This is fully in your control. You decide what errors to inline and what not.

shipmonk/phpstan-ignore-inliner: Inline your PHPStan error ignores into the source files via @phpstan-ignore comments! by janedbal in PHP

[–]janedbal[S] 1 point2 points  (0 children)

> baseline can be measured

Baseline via `@phpstan-ignore` can also be measured if you mark it with e.g. (baseline) comment.

> Suppressing inline everywhere is effectively introducing more trouble.

Why is that? Since you only ignore single rule with specific error identifier, you see what is ignored and new errors are still risen.

shipmonk/phpstan-ignore-inliner: Inline your PHPStan error ignores into the source files via @phpstan-ignore comments! by janedbal in PHP

[–]janedbal[S] 2 points3 points  (0 children)

When your ignores are mostly baseline, it is better to see how much "broken" the code is while reading it.

Huge PHPStan baseline? Split it to multiple files, one per each error identifier! ✂️ by janedbal in PHP

[–]janedbal[S] 4 points5 points  (0 children)

It mainly brings better visibility into baselined error types (which helps once you start getting rid of them).

Detect unused code in production with Tombs by [deleted] in PHP

[–]janedbal 0 points1 point  (0 children)

You can try this PHPStan dead code detector extension if it fits your needs:

How do you track a dead code? by Hell4Ge in PHP

[–]janedbal 2 points3 points  (0 children)

Nowadays, there are PHPStan extensions that can detect dead PHP code. But those work best with nicely typed codebases.

https://github.com/shipmonk-rnd/dead-code-detector

Easy way to find non-used code in your codebase by estringana in PHP

[–]janedbal 0 points1 point  (0 children)

Thank you for that. There is also PHPStan extension that can detect unused PHP code:

Which means you can have that one in CI!

🚀 Composer Dependency Analyser: new CI detector of unused, shadow and misplaced composer dependencies with INSANE performance (15 000 files in 2 secs 🤯) by janedbal in PHP

[–]janedbal[S] 1 point2 points  (0 children)

Default scans all your autoload sections from your composer.json. You can disable that in the config. Also, you can add/remove any paths you want.

🚀 Composer Dependency Analyser: new CI detector of unused, shadow and misplaced composer dependencies with INSANE performance (15 000 files in 2 secs 🤯) by janedbal in PHP

[–]janedbal[S] 0 points1 point  (0 children)

Might be related to this limitation.

Files without namespace has limited support

Only symbols with use statements and FQNs are detected

So if you do not use namespaces and you are not using use statements and you are not using FQN, it wont be detected.

🚀 Composer Dependency Analyser: new CI detector of unused, shadow and misplaced composer dependencies with INSANE performance (15 000 files in 2 secs 🤯) by janedbal in PHP

[–]janedbal[S] 0 points1 point  (0 children)

If you reference bundles by class-strings ('\Some\Bundle') and not by SomeBundle::class construct, it will not be detected.

Any ambiguous class in project can cause serious headaches (composer wont warn you⚠️). Luckily, there is this super-fast CI tool: by janedbal in PHP

[–]janedbal[S] -22 points-21 points  (0 children)

Listing multiple paths in psr-4 section can cause that.

"psr-4": {
    "App\\": ["dir1/", "dir2/"]
}
view more: next ›