SwiftLint
0.57.0
Un outil pour appliquer le style et les conventions Swift, librement basé sur le guide de style GitHub Swift désormais archivé. Swiftlint applique les règles de guide de style qui sont généralement acceptées par la communauté Swift. Ces règles sont bien décrites dans des guides de style populaires comme le guide de style Swift de Kodeco.
Swiftlint s'accroche à Clang et SourceKit pour utiliser la représentation AST de vos fichiers source pour des résultats plus précis.
Swiftlint peut être utilisé comme plugin de commande ou un plugin d'outil de construction.
Ajouter
. package ( url : " https://github.com/SimplyDanny/SwiftLintPlugins " , from : " <version> " ) à votre fichier Package.swift pour consommer automatiquement la dernière version de Swiftlint ou épingler la dépendance à une version spécifique:
. package ( url : " https://github.com/SimplyDanny/SwiftLintPlugins " , exact : " <version> " ) Là-bas, remplacez <version> par la version minimale ou exacte souhaitée.
Note
La consommation des plugins directement à partir du référentiel Swiftlint est livré avec plusieurs inconvénients. Pour les éviter et réduire les frais généraux imposés, il est fortement recommandé de consommer les plugins du référentiel dédié SwiftlintPlugins, même si les plugins du référentiel Swiftlint sont également absolument fonctionnels. Si les plugins de Swiftlint sont préférés, utilisez simplement l'URL https://github.com/realm/SwiftLint dans les déclarations de package ci-dessus.
Cependant, SwiftlintPlugins facilite massivement l'adoption du plugin. Il répertorie certaines des raisons qui entraînent les plugins tels que fournis par Swiftlint lui-même très gênant. Étant donné que le code du plugin et les versions sont maintenus en synchronisation, il n'y a pas de différence de fonctionnalité entre les deux, mais vous vous épargnez beaucoup de temps et de problème à l'aide du référentiel de plugins dédié.
Ce document suppose que vous comptez sur SwiftlintPlugins.
Utilisez le lien suivant pour ajouter Swiftlint comme dépendance de package à un projet Xcode:
https://github.com/SimplyDanny/SwiftLintPluginsbrew install swiftlint Ajoutez ce qui suit à votre Podfile :
pod 'SwiftLint' Cela téléchargera les binaires et dépendances Swiftlint dans Pods/ lors de votre prochaine exécution pod install et vous permettra de l'invoquer via ${PODS_ROOT}/SwiftLint/swiftlint dans vos phases de construction de script.
L'installation via Cocoapods permet également d'épingler une version spécifique de Swiftlint plutôt que simplement le dernier (ce qui est le cas avec Homebrew).
Notez que cela ajoutera les binaires Swiftlint, les binaires de ses dépendances et la distribution de la bibliothèque binaire Swift au Pods/ Directory, de sorte que la vérification de ce répertoire à SCM tel que GIT est découragée.
mint install realm/SwiftLint Mettez ceci dans votre MODULE.bazel :
bazel_dep ( name = "swiftlint" , version = "0.52.4" , repo_name = "SwiftLint" ) Ou mettez ceci dans votre WORKSPACE :
load ( "@bazel_tools//tools/build_defs/repo:http.bzl" , "http_archive" )
http_archive (
name = "build_bazel_rules_apple" ,
sha256 = "390841dd5f8a85fc25776684f4793d56e21b098dfd7243cd145b9831e6ef8be6" ,
url = "https://github.com/bazelbuild/rules_apple/releases/download/2.4.1/rules_apple.2.4.1.tar.gz" ,
)
load (
"@build_bazel_rules_apple//apple:repositories.bzl" ,
"apple_rules_dependencies" ,
)
apple_rules_dependencies ()
load (
"@build_bazel_rules_swift//swift:repositories.bzl" ,
"swift_rules_dependencies" ,
)
swift_rules_dependencies ()
load (
"@build_bazel_rules_swift//swift:extras.bzl" ,
"swift_rules_extra_dependencies" ,
)
swift_rules_extra_dependencies ()
http_archive (
name = "SwiftLint" ,
sha256 = "c6ea58b9c72082cdc1ada4a2d48273ecc355896ed72204cedcc586b6ccb8aca6" ,
url = "https://github.com/realm/SwiftLint/releases/download/0.52.4/bazel.tar.gz" ,
)
load ( "@SwiftLint//bazel:repos.bzl" , "swiftlint_repos" )
swiftlint_repos ()
load ( "@SwiftLint//bazel:deps.bzl" , "swiftlint_deps" )
swiftlint_deps ()Ensuite, vous pouvez exécuter Swiftlint dans le répertoire actuel avec cette commande:
bazel run -c opt @SwiftLint//:swiftlint Téléchargez SwiftLint.pkg à partir de la dernière version GitHub et exécutez-la.
Assurez-vous que le bazel de l'outil de construction et une récente chaîne d'outils Swift sont installés et que tous les outils sont découvrables sur votre PATH .
Pour construire Swiftlint, clonez ce référentiel et exécutez make install .
Important
Bien qu'il puisse sembler intuitif d'exécuter Swiftlint avant de compiler les fichiers source Swift pour quitter une construction tôt lorsqu'il y a des violations de charpèse, il est important de comprendre que Swiftlint est conçu pour analyser le code source valide qui est compilable. Le code non compilant peut très facilement conduire à des résultats inattendus et déroutants, en particulier lors de l'exécution avec des arguments de ligne de commande --fix / --autocorrect .
Swiftlint peut être utilisé comme plugin d'outils de construction pour les projets de package Swift et les projets Xcode.
Le plugin d'outil de construction détermine le répertoire de travail SwiftLint en localisant le fichier de configuration le plus haut dans le répertoire Package / Project. Si un fichier de configuration ne s'y trouve pas, le répertoire package / projet est utilisé comme répertoire de travail.
Le plugin lance une erreur lorsqu'il n'est pas en mesure de résoudre le répertoire de travail Swiftlint. Par exemple, cela se produira dans les projets Xcode où les fichiers Swift de la cible ne sont pas situés dans le répertoire du projet.
Pour maximiser la compatibilité avec le plugin, évitez les structures de projet qui nécessitent l'utilisation de l'option --config .
Note
Nécessite l'installation via Swift Package Manager.
Créer des plugins d'outils lors de la construction de chaque cible. Lorsqu'un projet a plusieurs cibles, le plugin doit être ajouté aux cibles souhaitées individuellement.
Pour ce faire, ajoutez le plugin à la ou les cibles pour être linée comme suit:
. target (
...
plugins : [ . plugin ( name : " SwiftLintBuildToolPlugin " , package : " SwiftLintPlugins " ) ]
) ,Note
Nécessite l'installation via Swift Package Manager.
Le plugin de commande permet d'exécuter SwiftLint à partir de la ligne de commande comme suit:
swift package plugin swiftlintNote
Nécessite l'installation via la dépendance du package Xcode.
Les plugins d'outils de construction s'exécutent en phase de construction de chaque cible. Lorsqu'un projet a plusieurs cibles, le plugin doit être ajouté aux cibles souhaitées individuellement.
Pour ce faire, ajoutez le SwiftLintBuildToolPlugin à la phase de Run Build Tool Plug-ins des Build Phases pour que la ou les cibles soient déverrouillées.
Conseil
Lorsque vous utilisez le plugin pour la première fois, assurez-vous de le faire confiance et de l'activer lorsque vous avez invité. Si un avertissement de construction de macros existe, sélectionnez-le pour faire confiance et activer les macros également.
Pour une utilisation sans surveillance (par exemple sur CI), le plugin de package et les validations de macro peuvent être désactivés avec l'une ou l'autre des éléments suivants:
Utilisation d'options xcodebuild :
-skipPackagePluginValidation
-skipMacroValidationRéglage des paramètres par défaut de xcode:
defaults write com.apple.dt.Xcode IDESkipPackagePluginFingerprintValidatation -bool YES
defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YESImportant
Les options d'utilisation sans surveillance contournent les boîtes de dialogue de validation de Xcode et font implicitement tous les plugins et macros, qui ont des implications de sécurité.
Les structures de projet où le fichier de configuration de SwiftLint est situé en dehors du répertoire Package / Project ne sont pas directement pris en charge par le plugin d'outil de construction. En effet, il n'est pas possible de transmettre des arguments pour créer des plugins d'outils (par exemple, passer le chemin du fichier de configuration).
Si votre structure de projet ne fonctionne pas directement avec le plugin d'outil de construction, veuillez considérer l'une des options suivantes:
parent_config: path/to/.swiftlint.yml .Note
En fonction de la méthode d'installation utilisée, la syntaxe de commande shell dans la phase de construction de script d'exécution peut être différente ou une configuration supplémentaire pourrait être nécessaire. Reportez-vous aux instructions d'installation pour plus d'informations.
Si le plugin d'outil de construction ne fonctionne pas pour la configuration de votre projet ou lorsque une configuration personnalisée supplémentaire est requise, Swiftlint peut être ajouté en tant que phase de construction de script d'exécution. Ceci est utile lorsqu'une configuration de projet repose sur l'option --config Swiftlint; ou pour peindre toutes les cibles ensemble en une seule invocation swiftlint . Les inclusions de fichiers et les exclusions peuvent être configurées dans la configuration .swiftlint.yml .
Pour ce faire, ajoutez un script personnalisé à une phase Run Script des Build Phases de la cible d'application principale, après la phase Compile Sources . Utilisez l'implémentation du script suivant:
if command -v swiftlint > /dev/null 2>&1
then
swiftlint
else
echo " warning: ` swiftlint ` command not found - See https://github.com/realm/SwiftLint#installation for installation instructions. "
fi Si vous utilisez le SwiftlintPlugin dans un package Swift, vous pouvez vous référer à l'exécutable swiftlint de la manière suivante:
SWIFT_PACKAGE_DIR= " ${BUILD_DIR % Build /* } SourcePackages/artifacts "
SWIFTLINT_CMD= $( ls " $SWIFT_PACKAGE_DIR " /swiftlintplugins/SwiftLintBinary/SwiftLintBinary.artifactbundle/swiftlint- * /bin/swiftlint | head -n 1 )
if test -f " $SWIFTLINT_CMD " 2>&1
then
" $SWIFTLINT_CMD "
else
echo " warning: ` swiftlint ` command not found - See https://github.com/realm/SwiftLint#installation for installation instructions. "
fi Note
Le chemin SWIFTLINT_CMD utilise la configuration Xcode par défaut et a été testé sur Xcode 15/16. Dans le cas d'une autre configuration (par exemple, un chemin de package Swift personnalisé), veuillez adapter les valeurs en conséquence.
Conseil
Décochez Based on dependency analysis pour exécuter swiftlint sur toutes les versions incrémentielles, supprimant l'avertissement de sorties non spécifiées.
Xcode 15 a apporté une modification significative en définissant la valeur par défaut du paramètre de génération ENABLE_USER_SCRIPT_SANDBOXING du NO à YES . En conséquence, Swiftlint rencontre une erreur liée aux autorisations de fichiers manquantes, qui se manifestent généralement comme error: Sandbox: swiftlint(19427) deny(1) file-read-data.
Pour résoudre ce problème, il est nécessaire de définir manuellement le paramètre ENABLE_USER_SCRIPT_SANDBOXING sur NO pour la cible spécifique pour laquelle Swiftlint est configuré.
Si vous avez installé Swiftlint via Homebrew sur Apple Silicon, vous pourriez vivre cet avertissement:
warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint En effet, Homebrew sur Apple Silicon installe les binaires dans le dossier /opt/homebrew/bin par défaut. Pour instruire Xcode où trouver Swiftlint, vous pouvez soit ajouter /opt/homebrew/bin à la variable d'environnement PATH dans votre phase de construction:
if [[ " $( uname -m ) " == arm64 ]]
then
export PATH= " /opt/homebrew/bin: $PATH "
fi
if command -v swiftlint > /dev/null 2>&1
then
swiftlint
else
echo " warning: ` swiftlint ` command not found - See https://github.com/realm/SwiftLint#installation for installation instructions. "
fi Ou vous pouvez créer un lien symbolique dans /usr/local/bin pointant vers le binaire réel:
ln -s /opt/homebrew/bin/swiftlint /usr/local/bin/swiftlint Si vous souhaitez également corriger les violations, votre script pourrait exécuter swiftlint --fix && swiftlint au lieu de swiftlint . Cela signifiera que toutes les violations corrigées sont fixées tout en garantissant que les avertissements apparaissent dans votre projet pour les violations restantes.
Si vous avez installé Swiftlint via Cocoapods, le script devrait ressembler à ceci:
" ${PODS_ROOT} /SwiftLint/swiftlint " Pour intégrer Swiftlint avec Visual Studio Code, installez l'extension vscode-swiftlint à partir du marché.
Vous pouvez utiliser l'action officielle swiftlint Fastlane pour exécuter Swiftlint dans le cadre de votre processus Fastlane.
swiftlint (
mode : :lint , # SwiftLint mode: :lint (default) or :autocorrect
executable : "Pods/SwiftLint/swiftlint" , # The SwiftLint binary path (optional). Important if you've installed it via CocoaPods
path : "/path/to/lint" , # Specify path to lint (optional)
output_file : "swiftlint.result.json" , # The path of the output file (optional)
reporter : "json" , # The custom reporter to use (optional)
config_file : ".swiftlint-ci.yml" , # The path of the configuration file (optional)
files : [ # List of files to process (optional)
"AppDelegate.swift" ,
"path/to/project/Model.swift"
] ,
ignore_exit_status : true , # Allow fastlane to continue even if SwiftLint returns a non-zero exit status (Default: false)
quiet : true , # Don't print status logs like 'Linting ' & 'Done linting' (Default: false)
strict : true # Fail on warnings? (Default: false)
) Swiftlint est également disponible sous forme d'image Docker à l'aide Ubuntu . Donc, la première fois, vous devez tirer l'image Docker en utilisant la commande suivante:
docker pull ghcr.io/realm/swiftlint:latest Puis les temps suivants, vous courez simplement swiftlint à l'intérieur du Docker comme:
docker run -it -v ` pwd ` : ` pwd ` -w ` pwd ` ghcr.io/realm/swiftlint:latest Cela exécutera swiftlint dans le dossier où vous êtes en ce moment ( pwd ), montrant une sortie comme:
$ docker run -it -v ` pwd ` : ` pwd ` -w ` pwd ` ghcr.io/realm/swiftlint:latest
Linting Swift files in current working directory
Linting ' RuleDocumentation.swift ' (1/490)
...
Linting ' YamlSwiftLintTests.swift ' (490/490)
Done linting ! Found 0 violations, 0 serious in 490 files.Ici, vous avez plus de documentation sur l'utilisation des images Docker.
$ swiftlint help
OVERVIEW: A tool to enforce Swift style and conventions.
USAGE: swiftlint <subcommand>
OPTIONS:
--version Show the version.
-h, --help Show help information.
SUBCOMMANDS:
analyze Run analysis rules
docs Open SwiftLint documentation website in the default web browser
generate-docs Generates markdown documentation for selected group of rules
lint (default) Print lint warnings and errors
baseline Operations on existing baselines
reporters Display the list of reporters and their identifiers
rules Display the list of rules and their identifiers
version Display the current version of SwiftLint
See 'swiftlint help <subcommand>' for detailed help. Exécutez swiftlint dans le répertoire contenant les fichiers Swift en peluche. Les répertoires seront recherchés récursivement.
Pour spécifier une liste de fichiers lors de l'utilisation lint ou analyze (comme la liste des fichiers modifiés par Xcode spécifié par le plugin Xcode ExtraBuildPhase , ou des fichiers modifiés dans l'arborescence de travail basée sur git ls-files -m ), vous pouvez le faire en passant L'option --use-script-input-files et définit les variables d'instance suivantes: SCRIPT_INPUT_FILE_COUNT et SCRIPT_INPUT_FILE_0 , SCRIPT_INPUT_FILE_1 , ..., SCRIPT_INPUT_FILE_{SCRIPT_INPUT_FILE_COUNT - 1} . De même, les fichiers peuvent être lus à partir des listes de fichiers en passant l'option --use-script-input-file-lists et en définissant les variables d'instance suivantes: SCRIPT_INPUT_FILE_LIST_COUNT et SCRIPT_INPUT_FILE_LIST_0 , SCRIPT_INPUT_FILE_LIST_1 , SCRIPT_INPUT_FILE_LIST_{SCRIPT_INPUT_FILE_LIST_COUNT - 1} .
Ce sont les mêmes variables d'environnement définies pour les fichiers d'entrée dans les phases de script Xcode personnalisées.
Swiftlint s'accroche à SourceKit pour qu'il continue de fonctionner même si Swift évolue!
Cela maintient également Swiftlint Lean, car il n'a pas besoin d'expédier avec un compilateur Swift complet, il communique simplement avec celui officiel que vous avez déjà installé sur votre machine.
Vous devez toujours exécuter Swiftlint avec la même chaîne d'outils que vous utilisez pour compiler votre code.
Vous souhaiterez peut-être remplacer la chaîne d'outils Swift par défaut de Swiftlint si vous avez installé plusieurs chaînes d'outils ou Xcodes.
Voici l'ordre dans lequel Swiftlint détermine la chaîne d'outils Swift à utiliser:
$XCODE_DEFAULT_TOOLCHAIN_OVERRIDE$TOOLCHAIN_DIR ou $TOOLCHAINSxcrun -find swift/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain~/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain~/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain sourcekitd.framework devrait être trouvé dans le sous-répertoire usr/lib/ de la valeur transmise dans les chemins ci-dessus.
Vous pouvez également définir la variable d'environnement TOOLCHAINS sur la notation inverse-DNS qui identifie une version de la chaîne d'outils Swift:
TOOLCHAINS=com.apple.dt.toolchain.Swift_2_3 swiftlint --fix Sur Linux, SourceKit devrait être situé dans /usr/lib/libsourcekitdInProc.so ou spécifié par la variable d'environnement LINUX_SOURCEKIT_LIB_PATH .
pre-commit Hook Swiftlint peut être exécuté comme un crochet pré-engagé. Une fois installé, ajoutez-le au .pre-commit-config.yaml dans la racine de votre référentiel:
repos :
- repo : https://github.com/realm/SwiftLint
rev : 0.50.3
hooks :
- id : swiftlint Ajustez rev à la version Swiftlint de votre choix. pre-commit autoupdate peut être utilisé pour mettre à jour la version actuelle.
Swiftlint peut être configuré à l'aide entry pour appliquer des correctifs et échouer sur les erreurs:
- repo : https://github.com/realm/SwiftLint
rev : 0.50.3
hooks :
- id : swiftlint
entry : swiftlint --fix --strict Plus de 200 règles sont incluses dans Swiftlint et la communauté Swift (c'est vous!) Continue de contribuer davantage au fil du temps. Les demandes de traction sont encouragées.
Vous pouvez trouver une liste mise à jour de règles et plus d'informations à leur sujet ici.
Vous pouvez également consulter le répertoire Source / SwiftlintBuilTinrules / Rules pour voir leur implémentation.
opt_in_rules sont désactivés par défaut (c'est-à-dire, vous devez les activer explicitement dans votre fichier de configuration).
Lignes directrices sur le moment de marquer une règle comme opt-in:
empty_count )force_unwrapping )Les règles peuvent être désactivées avec un commentaire dans un fichier source avec le format suivant:
// swiftlint:disable <rule1> [<rule2> <rule3>...]
Les règles seront désactivées jusqu'à la fin du fichier ou jusqu'à ce que le Linter voit un commentaire d'activation de correspondance:
// swiftlint:enable <rule1> [<rule2> <rule3>...]
Par exemple:
// swiftlint:disable colon
let noWarning : String = " " // No warning about colons immediately after variable names!
// swiftlint:enable colon
let hasWarning : String = " " // Warning generated about colons immediately after variable names Y compris le mot-clé all désactiver toutes les règles jusqu'à ce que le linter voit un commentaire d'activation de correspondance:
// swiftlint:disable all // swiftlint:enable all
Par exemple:
// swiftlint:disable all
let noWarning : String = " " // No warning about colons immediately after variable names!
let i = " " // Also no warning about short identifier names
// swiftlint:enable all
let hasWarning : String = " " // Warning generated about colons immediately after variable names
let y = " " // Warning generated about short identifier names Il est également possible de modifier une commande disable ou enable en ajoutant :previous , :this ou :next pour appliquer la commande uniquement à la ligne précédente, cette ligne (actuelle) ou suivante respectivement.
Par exemple:
// swiftlint:disable:next force_cast
let noWarning = NSNumber ( ) as! Int
let hasWarning = NSNumber ( ) as! Int
let noWarning2 = NSNumber ( ) as! Int // swiftlint:disable:this force_cast
let noWarning3 = NSNumber ( ) as! Int
// swiftlint:disable:previous force_cast Exécutez swiftlint rules pour imprimer une liste de toutes les règles disponibles et de leurs identifiants.
Configurez Swiftlint en ajoutant un fichier .swiftlint.yml à partir du répertoire à partir duquel vous exécutez Swiftlint. Les paramètres suivants peuvent être configurés:
Inclusion des règles:
disabled_rules : Désactiver les règles de la définition pertinente par défaut.opt_in_rules : Activez les règles qui ne font pas partie de l'ensemble par défaut. L'identifiant all permettra à toutes les règles OPT dans Linter, à l'exception de celles répertoriées dans disabled_rules .only_rules : seules les règles spécifiées dans cette liste seront activées. Ne peut pas être spécifié aux côtés de disabled_rules ou opt_in_rules .analyzer_rules : Il s'agit d'une liste de règles entièrement distincte qui ne sont exécutées que par la commande analyze . Toutes les règles de l'analyseur sont opt, il s'agit donc de la seule liste de règles configurable, il n'y a pas d'équivalents pour disabled_rules et only_rules . L'identifiant all peut également être utilisé ici pour activer toutes les règles de l'analyseur, à l'exception de celles énumérées dans disabled_rules . # By default, SwiftLint uses a set of sensible default rules you can adjust:
disabled_rules : # rule identifiers turned on by default to exclude from running
- colon
- comma
- control_statement
opt_in_rules : # some rules are turned off by default, so you need to opt-in
- empty_count # find all the available rules by running: `swiftlint rules`
# Alternatively, specify all rules explicitly by uncommenting this option:
# only_rules: # delete `disabled_rules` & `opt_in_rules` if using this
# - empty_parameters
# - vertical_whitespace
analyzer_rules : # rules run by `swiftlint analyze`
- explicit_self
# Case-sensitive paths to include during linting. Directory paths supplied on the
# command line will be ignored.
included :
- Sources
excluded : # case-sensitive paths to ignore during linting. Takes precedence over `included`
- Carthage
- Pods
- Sources/ExcludedFolder
- Sources/ExcludedFile.swift
- Sources/*/ExcludedFile.swift # exclude files with a wildcard
# If true, SwiftLint will not fail if no lintable files are found.
allow_zero_lintable_files : false
# If true, SwiftLint will treat all warnings as errors.
strict : false
# If true, SwiftLint will treat all errors as warnings.
lenient : false
# The path to a baseline file, which will be used to filter out detected violations.
baseline : Baseline.json
# The path to save detected violations to as a new baseline.
write_baseline : Baseline.json
# If true, SwiftLint will check for updates after linting or analyzing.
check_for_updates : true
# configurable rules can be customized from this configuration file
# binary rules can set their severity level
force_cast : warning # implicitly
force_try :
severity : warning # explicitly
# rules that have both warning and error levels, can set just the warning level
# implicitly
line_length : 110
# they can set both implicitly with an array
type_body_length :
- 300 # warning
- 400 # error
# or they can set both explicitly
file_length :
warning : 500
error : 1200
# naming rules can set warnings/errors for min_length and max_length
# additionally they can set excluded names
type_name :
min_length : 4 # only warning
max_length : # warning and error
warning : 40
error : 50
excluded : iPhone # excluded via string
allowed_symbols : ["_"] # these are allowed in type names
identifier_name :
min_length : # only min_length
error : 4 # only error
excluded : # excluded via string array
- id
- URL
- GlobalAPIKey
reporter : " xcode " # reporter type (xcode, json, csv, checkstyle, codeclimate, junit, html, emoji, sonarqube, markdown, github-actions-logging, summary) Vous pouvez également utiliser des variables d'environnement dans votre fichier de configuration, en utilisant ${SOME_VARIABLE} dans une chaîne.
En plus des règles avec lesquelles le principal projet Swiftlint est livré, Swiftlint peut également exécuter deux types de règles personnalisées que vous pouvez vous définir dans vos propres projets:
Ces règles sont écrites de la même manière que les règles basées sur Swift qui expédient avec Swiftlint afin qu'elles soient rapides, précises, peuvent tirer parti de SwiftsyNTAX, peuvent être testées unitaires, et plus encore.
L'utilisation nécessite de construire Swiftlint avec Bazel comme décrit dans cette vidéo ou son code associé dans github.com/jpsim/swiftlint-bazel-example.
Vous pouvez définir des règles basées sur Regex personnalisées dans votre fichier de configuration à l'aide de la syntaxe suivante:
custom_rules :
pirates_beat_ninjas : # rule identifier
included :
- " .* \ .swift " # regex that defines paths to include during linting. optional.
excluded :
- " .*Test \ .swift " # regex that defines paths to exclude during linting. optional
name : " Pirates Beat Ninjas " # rule name. optional.
regex : " ([nN]inja) " # matching pattern
capture_group : 0 # number of regex capture group to highlight the rule violation at. optional.
match_kinds : # SyntaxKinds to match. optional.
- comment
- identifier
message : " Pirates are better than ninjas. " # violation message. optional.
severity : error # violation severity. optional.
no_hiding_in_strings :
regex : " ([nN]inja) "
match_kinds : stringVoici à quoi ressemblerait la sortie:
Il est important de noter que le modèle d'expression régulière est utilisé avec les drapeaux s et m activés, c'est-à-dire . correspond à Newlines et ^ / $ correspondent respectivement au début et à la fin des lignes. Si vous ne voulez pas avoir . Faites correspondre les Newlines, par exemple, le regex peut être apparenté par (?-s) .
Vous pouvez filtrer les correspondances en fournissant un ou plusieurs match_kinds , qui rejetera les matchs qui incluent des types de syntaxe qui ne sont pas présents dans cette liste. Voici tous les types de syntaxe possibles:
argumentattribute.builtinattribute.idbuildconfig.idbuildconfig.keywordcommentcomment.markcomment.urldoccommentdoccomment.fieldidentifierkeywordnumberobjectliteralparameterplaceholderstringstring_interpolation_anchortypeidentifier Tous les types de syntaxe utilisés dans un extrait de code Swift peuvent être extraits en demandant à SourceKitten. Par exemple, sourcekitten syntax --text "struct S {}" fournit
source.lang.swift.syntaxtype.keyword pour le mot-clé struct etsource.lang.swift.syntaxtype.identifier pour son nom S qui correspondent au keyword et identifier dans la liste ci-dessus.
Si vous utilisez des règles personnalisées en combinaison avec only_rules , vous devez inclure la chaîne littérale custom_rules dans la liste only_rules :
only_rules :
- custom_rules
custom_rules :
no_hiding_in_strings :
regex : " ([nN]inja) "
match_kinds : stringContrairement aux règles personnalisées Swift, vous pouvez utiliser des builds Swiftlint officiels (par exemple à partir de Homebrew) pour exécuter les règles personnalisées regex.
Swiftlint peut corriger automatiquement certaines violations. Les fichiers sur disque sont écrasés avec une version corrigée.
Veuillez vous assurer d'avoir des sauvegardes de ces fichiers avant d'exécuter swiftlint --fix , sinon des données importantes peuvent être perdues.
La lignée standard est désactivée tout en corrigeant en raison de la forte probabilité de violations (ou de leurs décalages) incorrectes après avoir modifié un fichier lors de l'application de corrections.
La commande swiftlint analyze peut peluchez des fichiers Swift à l'aide de l'AST complet à vérification. Le chemin de journal du compilateur contenant l'invocation de la commande de build swiftc propre (les versions incrémentielles échoueront) doivent être transmises pour analyze via l'indicateur --compiler-log-path . par exemple --compiler-log-path /path/to/xcodebuild.log
Cela peut être obtenu par
xcodebuild -workspace {WORKSPACE}.xcworkspace -scheme {SCHEME} > xcodebuild.logswiftlint analyze --compiler-log-path xcodebuild.logLes règles de l'analyseur ont tendance à être considérablement plus lentes que les règles de peluche.
Swiftlint propose une variété de façons d'inclure plusieurs fichiers de configuration. Plusieurs fichiers de configuration sont fusionnés dans une seule configuration qui est ensuite appliquée comme un seul fichier de configuration serait appliqué.
Il existe de nombreux cas d'utilisation où l'utilisation de plusieurs fichiers de configuration pourrait être utile:
Par exemple, on peut utiliser une configuration SwiftLint partagée à l'échelle de l'équipe tout en permettant des remplacements dans chaque projet via un fichier de configuration enfant.
Configuration à l'échelle de l'équipe:
disabled_rules :
- force_castConfiguration spécifique au projet:
opt_in_rules :
- force_cast Vous pouvez spécifier une référence child_config et / ou une référence parent_config dans un fichier de configuration. Ces références doivent être des chemins locaux par rapport au dossier du fichier de configuration dans lequel ils sont spécifiés.
Une configuration d'enfant est traitée comme un raffinement et a donc une priorité plus élevée , tandis qu'une configuration parent est considérée comme une base avec une priorité plus faible en cas de conflits.
Voici un exemple, en supposant que vous avez la structure de fichiers suivante:
ProjectRoot
|_ .swiftlint.yml
|_ .swiftlint_refinement.yml
|_ Base
|_ .swiftlint_base.yml Pour inclure à la fois le raffinement et le fichier de base, votre .swiftlint.yml devrait ressembler à ceci:
child_config : .swiftlint_refinement.yml
parent_config : Base/.swiftlint_base.yml Lors de la fusion des configurations parent et enfant, les configurations included et excluded sont soigneusement traitées pour tenir compte des différences dans l'emplacement du répertoire des fichiers de configuration contenant.
Tout comme vous pouvez fournir des références locales child_config / parent_config , au lieu de référencer les chemins locaux, vous pouvez simplement mettre des URL qui mènent à des fichiers de configuration. Pour que Swiftlint détecte ces références distantes, elles doivent commencer par http:// ou https:// .
Les fichiers de configuration à distance référencés peuvent même référencer d'autres fichiers de configuration à distance, mais ne sont pas autorisés à inclure des références locales.
À l'aide d'une référence distante, votre .swiftlint.yml pourrait ressembler à ceci:
parent_config : https://myteamserver.com/our-base-swiftlint-config.ymlChaque fois que vous exécutez Swiftlint et que vous avez une connexion Internet, Swiftlint essaie d'obtenir une nouvelle version de chaque configuration distante référencée. Si cette demande met à jour, une version en cache est utilisée si disponible. S'il n'y a pas de version mise en cache disponible, Swiftlint échoue - mais pas de soucis, une version en cache devrait être là une fois que Swiftlint s'est déroulé avec succès au moins une fois.
Si nécessaire, les délais d'expiration de la récupération de la configuration distante peuvent être spécifiés manuellement via les fichiers de configuration à l'aide des spécificateurs remote_timeout / remote_timeout_if_cached . Ces valeurs par défaut à 2 secondes ou 1 seconde, respectivement.
Au lieu de simplement fournir un fichier de configuration lors de l'exécution de Swiftlint via la ligne de commande, vous pouvez également passer une hiérarchie, où la première configuration est traitée comme un parent, tandis que la dernière est traitée comme l'enfant la plus prioritaire.
Un exemple simple comprenant seulement deux fichiers de configuration ressemble à ceci:
swiftlint --config .swiftlint.yml --config .swiftlint_child.yml
En plus d'une configuration principale (le fichier .swiftlint.yml dans le dossier racine), vous pouvez mettre d'autres fichiers de configuration nommés .swiftlint.yml dans la structure du répertoire qui sont ensuite fusionnées en tant que configuration d'enfant, mais uniquement avec un effet pour ceux Fichiers qui sont dans le même répertoire que la configuration ou dans un répertoire plus profond où il n'y a pas un autre fichier de configuration. En d'autres termes: les configurations imbriquées ne fonctionnent pas récursivement - il y a un nombre maximum d'une configuration imbriquée par fichier qui peut être appliquée en plus de la configuration principale.
.swiftlint.yml Les fichiers ne sont considérés que comme une configuration imbriquée si elles n'ont pas été utilisées pour créer déjà la configuration principale (par exemple en ayant été référencée via quelque chose comme child_config: Folder/.swiftlint.yml ). De plus, les spécifications parent_config / child_config des configurations imbriquées sont ignorées car il n'y a aucun sens à cela.
Si un (ou plusieurs) fichiers Swiftlint sont explicitement spécifiés via le paramètre --config , cette configuration sera traitée comme un remplacement, peu importe qu'il existe d'autres fichiers .swiftlint.yml quelque part dans le répertoire. Donc, si vous souhaitez utiliser des configurations imbriquées, vous ne pouvez pas utiliser le paramètre --config .
MIT sous licence.
Swiftlint est maintenu et financé par Realm Inc. Les noms et les logos de Realm sont des marques de Realm Inc.
Nous ❤️ logiciel open source! Voir nos autres projets open source, lire notre blog ou dire salut sur Twitter (@Realm).
Nos remerciements à MacStadium pour avoir fourni un Mac Mini pour exécuter nos tests de performance.
