Ideally, SwiftLintCore would some day only contain components
that are needed to define rules. Consequently, it would be the
only bundle required to import for (external) rule development.
Over the years, SwiftLintFramework had become a fairly massive monolith,
containing over 400 source files with both core infrastructure and
rules.
Architecturally, the rules should rely on the core infrastructure but
not the other way around. There are two exceptions to this:
`custom_rules` and `superfluous_disable_command` which need special
integration with the linter infrastructure.
Now the time has come to formalize this architecture and one way to do
that is to move the core SwiftLint functionality out of
SwiftLintFramework and into a new SwiftLintCore module that the rules
can depend on.
Beyond enforcing architectural patterns, this also has the advantage of
speeding up incremental compilation by skipping rebuilding the core
functionality when iterating on rules.
Because the core functionality is always useful when building rules, I'm
opting to import SwiftLintCore in SwiftLintFramework as `@_exported` so
that it's implicitly available to all files in SwiftLintFramework
without needing to import it directly.
In a follow-up I'll also split the built-in rules and the extra rules
into their own modules. More modularization is possible from there, but
not planned.
The bulk of this PR just moves files from `Source/SwiftLintFramework/*`
to `Source/SwiftLintCore/*`. There are some other changes that can't be
split up into their own PRs:
* Change jazzy to document the SwiftLintCore module instead of
SwiftLintFramework.
* Change imports in unit tests to reflect where code was moved to.
* Update `sourcery` make rule to reflect where code was moved to.
* Create a new `coreRules` array and register those rules with the
registry. This allows the `custom_rules` and
`superfluous_disable_command` rule implementations to remain internal
to the SwiftLintCore module, preventing more implementation details
from leaking across architectural layers.
* Move `RuleRegistry.registerAllRulesOnce()` out of the type declaration
and up one level so it can access rules defined downstream from
SwiftLintCore.
* Migrate LinterCache to use Codable models
improving performance and type safety
* Fix Linux
* Avoid creating a Decoder if it won't be used
For example if the file doesn't exist or can't be read.
* Use corelibs plist coder if available
It's available in the Swift 5.1 branch: https://github.com/apple/swift-corelibs-foundation/pull/1849
* Remove unused error case
* Split cache into one file per configuration
* Only write cache files with changes
* Avoid converting from Data -> String -> Data when saving cache files
* Move empty check to for where
* Split cache changelog entry
* Reword changelog entry to better reflect impact
The MIT license doesn't require that all files be prepended with this
licensing or copyright information. Realm confirmed that they're ok with this
change. This will enable some companies to contribute to SwiftLint and the
date & authorship information will remain accessible via git source control.
This has never worked for two reasons:
1. We've used dictionaries to represent cache descriptions, which
don't guarantee stable ordering of keys across invocations.
This is true both on Darwin and Linux, but in practice ordering
varies significantly more on Linux.
2. Storing a `TimeInterval` value in a `[String: Any]` dictionary
and retrieving it again will not be dynamically castable to
`Double` or `TimeInterval` but will be castable to `Int`.
Danny Mösch
JP Simard
Paul Taykalo
Colton Schlosser
Norio Nomura
Marcelo Fabri
Víctor Pimentel
Marcelo Fabri