Ability to use custom header prefix #1389
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
can you update the param names etc? it using old that don't match what it's doing since we are no longer hiding |
In this PR I created param Do you mean that I should rename param |
| @@ -118,8 +118,9 @@ func runCLI() { | |||
| Option<Path>("ejsPath", default: "", description: "Path to EJS file for JavaScript templates."), | |||
| Option<Path>("cacheBasePath", default: "", description: "Base path to Sourcery's cache directory"), | |||
| Option<Path>("buildPath", default: "", description: "Sets a custom build path"), | |||
| Flag("hideVersionHeader", description: "Do not include Sourcery version in the generated files headers.") | |||
| ) { watcherEnabled, disableCache, verboseLogging, logAST, logBenchmark, parseDocumentation, quiet, prune, serialParse, sources, excludeSources, templates, excludeTemplates, output, isDryRun, configPaths, forceParse, baseIndentation, args, ejsPath, cacheBasePath, buildPath, hideVersionHeader in | |||
| Flag("hideVersionHeader", description: "Do not include Sourcery version in the generated files headers."), | |||
| @@ -301,8 +303,9 @@ func runCLI() { | |||
| """), | |||
| Option<Path>("cacheBasePath", default: "", description: "Base path to Sourcery's cache directory"), | |||
| Option<Path>("buildPath", default: "", description: "Sets a custom build path"), | |||
| Flag("hideVersionHeader", description: "Do not include Sourcery version in the generated files headers.") | |||
| ) { disableCache, verboseLogging, logAST, logBenchmark, parseDocumentation, quiet, prune, serialParse, sources, excludeSources, templates, excludeTemplates, output, isDryRun, configPaths, forceParse, baseIndentation, args, cacheBasePath, buildPath, hideVersionHeader in | |||
| Flag("hideVersionHeader", description: "Do not include Sourcery version in the generated files headers."), | |||
|
I marked the old code that doesn't seem should be part of this pr |
|
Oh, the old parameter |
krzysztofzablocki
merged commit 3d3a2be
into
krzysztofzablocki:master
1 of 2 checks passed
|
Oh I misread it, forgot it existed ¯_(ツ)_/¯ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds ability to add additional prefix before header in generated files
Problem
If you use SwiftLint rule "file_name", then you will catch "File Name Violation" errors/warnings for each generated file. Even if you have "swiftlint:disable all" after header.
Also we have swiftlint rule for file header pattern "file_header" which also throws a warning :(
Solution
I found a similar problem in the SwiftLint repo - realm/SwiftLint#2277. Users suggest to add this line at the beginning of the file (at 0 line)
// swiftlint:disable:this file_name.But at the moment this line contains header comment
// Generated using Sourcery .... And I thought that if we be able to add additional custom prefix before the header with the following line// swiftlint:disable:this file_name, then we could solve this problem.