shipmonk-rnd/composer-dependency-analyser

Allow to ignore errors on class rather than package

Closed this issue · 3 comments

composer-require-check has a symbol-whitelist config which allows to disable error for specific classes.

I would prefer having to write

->ignoreErrorsOnClass("Symfony\\Bridge\\Twig\\TokenParser\\DumpTokenParser", ...)

rather than

->ignoreErrorsOnPackage('symfony/twig-bridge', ...)

because this way if I add another class I have to check if it was voluntary or not.

On the same way ignoreErrorsOnClassAndPath could exists.

@janedbal looking at IgnoreList::shouldIgnoreError the implementation doesn't seems to hard but you might need to decide how the API would evolve, ie:

  • Do we add ignoreErrorsOnClass and ignoreErrorsOnClassRegex
  • Do we add ignoreErrorsOnClass and ignoreErrorsOnFunction
  • Do we just add ignoreErrorsOnSymbol
  • ...

What is the motivation behind this? Which error type are you targetting? Because:

  • unused dependency: Has no references.
  • shadow depenency: I cannot imagine why should I target classes.
  • dev-in-prod & prod-in-dev: Are you suggesting that for part of the classes it is ok to have such violation, but not for the rest of from that package? Can you give me example?

Regarding the API, question is if we want to support full matrix or not. Currently we have:

  • ignore globally
  • ignore by path
  • ignore by package
  • ignore by path & package

With the new class-based ignore, it is questionable if we want full matrix support:

  • ignore globally
  • ignore by path
  • ignore by package
  • ignore by class
  • ignore by path & package
  • ignore by path & class
  • ignore by package & class
  • ignore by path, package, class

And even more questionable if class & function is added:

  • ignore globally
  • ignore by path
  • ignore by package
  • ignore by class
  • ignore by function
  • ignore by path & package
  • ignore by path & class
  • ignore by path & function
  • ignore by package & class
  • ignore by package & function
  • ignore by class & function
  • ignore by path, package, class
  • ignore by path, package, function
  • ignore by path, class, function
  • ignore by package, class, function
  • ignore by path, package, class, function

dev-in-prod & prod-in-dev: Are you suggesting that for part of the classes it is ok to have such violation, but not for the rest of from that package? Can you give me example?

Sure.

My use case was the fact that I had a src folder with prod code but the src/Foo folder was used only in a dev context.
So I wanted to allow dev-in-prod dependency for the src/Foo folder.

But I think I solved my issue with

    ->addPathToScan(__DIR__.'/src/Foo', isDev: true)
    ->addPathToScan(__DIR__.'/src', isDev: false)

so this may be closed.