You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DEFAULT_IGNORE_PATTERNS includes vendor/**/*, and Definition#add_ignore_patterns only
ever appends (@ignore_patterns |= …). There is no DSL affordance to drop a default ignore,
so a Rails app whose engines live in vendor/engines/ cannot analyse them at all.
This interacts badly with two other facts:
DEFAULT_SOURCE_PATTERNS already lists engines/*/app/**/*.rb, so engines are clearly
meant to be in scope — just not at the path Rails has historically used for them.
Analyzer#ruby_files applies ignored as a final reject, after Definition#analysis_patterns has unioned in every component's file_patterns. So the DSL
documentation ("Component patterns are always analyzed, so most projects never need this")
does not hold against a default ignore: the component comes out empty and every rule on it
is vacuously satisfied — the same shape as Analyse .rake files (source globs matching *.rake are silently dropped) #24.
Declaring source does not help either, and makes things worse:
sourcereplaces the defaults rather than adding to them, and the ignore still wins.
Measured
A Rails app with three tenant engines under vendor/engines/ (184 .rb files), on 1.1.0:
Spec
files reported
Engines analysed
components declared on vendor/engines/*/**/*.rb
3532 (= app + lib + spec exactly)
no
same, plus source "vendor/engines/**/*.rb"
2211 (defaults lost)
no
separate spec with root 'vendor/engines'
184
yes
archspec explain vendor/engines/engine_a/app/helpers/some_helper.rb returns no file or constant found.
Two boundary rules — "no engine may reference another engine's namespace" and "the host app
may not call an engine operation" — reported 0 violations while checking nothing. They were
only caught because a deliberate violation was injected and stayed green.
The root 'vendor/engines' workaround does analyse the engines, but that graph excludes the
host application, so any rule spanning host → engine is unexpressible in it.
Suggestion
Any of these would be enough:
let ignore remove a default, e.g. ignore '!vendor/**/*' or unignore 'vendor/engines/**/*';
exempt explicit component file_patterns from the default ignores (keeping user-declared
ignores authoritative), which would match what the DSL docs already promise;
add vendor/engines/*/app/**/*.rb to DEFAULT_SOURCE_PATTERNS and narrow the default
ignore to vendor/bundle/**/* and friends.
Either way, a component whose glob matches files on disk but resolves to zero analysed files
is worth a warning — that silence is what makes this class of bug survive.
Summary
DEFAULT_IGNORE_PATTERNSincludesvendor/**/*, andDefinition#add_ignore_patternsonlyever appends (
@ignore_patterns |= …). There is no DSL affordance to drop a default ignore,so a Rails app whose engines live in
vendor/engines/cannot analyse them at all.This interacts badly with two other facts:
DEFAULT_SOURCE_PATTERNSalready listsengines/*/app/**/*.rb, so engines are clearlymeant to be in scope — just not at the path Rails has historically used for them.
Analyzer#ruby_filesappliesignoredas a finalreject, afterDefinition#analysis_patternshas unioned in every component'sfile_patterns. So the DSLdocumentation ("Component patterns are always analyzed, so most projects never need this")
does not hold against a default ignore: the component comes out empty and every rule on it
is vacuously satisfied — the same shape as Analyse .rake files (source globs matching *.rake are silently dropped) #24.
Declaring
sourcedoes not help either, and makes things worse:sourcereplaces the defaults rather than adding to them, and the ignore still wins.Measured
A Rails app with three tenant engines under
vendor/engines/(184.rbfiles), on 1.1.0:filesreportedvendor/engines/*/**/*.rbapp+lib+specexactly)source "vendor/engines/**/*.rb"root 'vendor/engines'archspec explain vendor/engines/engine_a/app/helpers/some_helper.rbreturnsno file or constant found.Two boundary rules — "no engine may reference another engine's namespace" and "the host app
may not call an engine operation" — reported 0 violations while checking nothing. They were
only caught because a deliberate violation was injected and stayed green.
Use case
The
root 'vendor/engines'workaround does analyse the engines, but that graph excludes thehost application, so any rule spanning host → engine is unexpressible in it.
Suggestion
Any of these would be enough:
ignoreremove a default, e.g.ignore '!vendor/**/*'orunignore 'vendor/engines/**/*';file_patternsfrom the default ignores (keeping user-declaredignores authoritative), which would match what the DSL docs already promise;
vendor/engines/*/app/**/*.rbtoDEFAULT_SOURCE_PATTERNSand narrow the defaultignore to
vendor/bundle/**/*and friends.Either way, a component whose glob matches files on disk but resolves to zero analysed files
is worth a warning — that silence is what makes this class of bug survive.