jamitlabs / projlint Goto Github PK

A rule that allows to specify how the files in a directory should be structured and what kind of files are allowed. An example configuration could look something like this:

- rules:
  - directory_structure:
      - App/Sources:
          apply_to_subfolders: true
          allowed_files_regex: ".*\\.swift"
      - App/Sources/Extensions:
          apply_to_subfolders: true
          allowed_files_regex: ".*Extension\\.swift"
      - App/SupportingFiles:
          apply_to_subfolders: true
          disallowed_files_regex: ".*\\.swift"

Currently when using .projlint.yml and using the rule file_content_template and comparing the file with a remote template, it's sometimes a little inflexible to not be able to add project-specific additional rules that only apply in this project. There could be either support for specifying multiple .yml files to solve this problem or a default second yml file which can be used to define project-specific rules. The default second file could be named .projlint-local.yml or .projlint-private.yml.

A rule that allows to check git messages in specified branches (also defineable through regexes) using regexes. An example configuration could be something like this:

rules:
  - git_message_regex:
      branch: work/.*
      last_commits_count: 10
      matching: "\\A(?:\\[[^\\]]+\\] )?[A-Z](?:.){,49}(?:\\n\\n\\S.*)?\\z"

Whereas the branch value active could always only lint the active branch.

In combination with Overcommit (which could run ProjLint before committing) this rule would be even useful during development.

The current reports of lint errors and warnings contain too much informations.

It would be a great advancement of the tool to reduce the informations reported to a more user-friendly representation.

Improvement suggestions:

• Categorizing Reports by Type
• Highlighting the issue sources with colors
• Better indentation and formatting for readability
• Removing informations about the executed commands like diff ...

A new rule with which you can check whether a file exists or not. This can be used to make sure projects use specific tools (like Carthage over CocoaPods) or have specific configuration files (like a .gitignore or .swiftlint.yml).

@Dschee When running tools install ProjlLint won't be updated. Due to the recent addition of the --strict flag in ProjLint the ci lint command failed for me so I had to update it by myself. This is not a big issue but updating ProjLint when running tools install would ensure an even smoother experience imo.

A new rule that allows to check if specific build phases exist and are ordered correctly. For example the configuration could look like this:

- rules:
  - xcode_build_phases:
      project: {{project_name}}.xcodeproj
      target: App
      run_scripts:
        - BartyCrouch: |
            if which bartycrouch > /dev/null; then
                # Incrementally update all Storyboards/XIBs strings files
                bartycrouch interfaces -p "$PROJECT_DIR/App/Sources"

                # Add new keys to Localizable.strings files from NSLocalizedString in code
                bartycrouch code -p "$PROJECT_DIR/App/Sources" -l "$PROJECT_DIR/App/Resources" -a -s -e

                # Normalize your Strings files to keep them nice and clean
                bartycrouch normalize -p "$PROJECT_DIR/App" -l en -d -w -h -s
            else
                echo "warning: BartyCrouch not installed, download it from https://github.com/Flinesoft/BartyCrouch"
            fi
        - SwiftGen: |
            if which swiftgen > /dev/null; then
                swiftgen strings "$PROJECT_DIR/App/Resources/en.lproj/Localizable.strings" -t structured-swift4 -o "$PROJECT_DIR/App/Generated/SwiftGen/Strings.swift"
                swiftgen storyboards "$PROJECT_DIR/App/Sources" -t swift4 -o "$PROJECT_DIR/App/Generated/SwiftGen/Storyboards.swift"
                swiftgen xcassets "$PROJECT_DIR/App/Resources/Colors.xcassets" -p "$PROJECT_DIR/SwiftGen-Colors.stencil" -o "$PROJECT_DIR/App/Generated/SwiftGen/Colors.swift"
            else
                echo "warning: SwiftGen not installed, download it from https://github.com/AliSoftware/SwiftGen"
            fi
        - SwiftLint: |
            if which swiftlint > /dev/null; then
                swiftlint
            else
                echo "warning: SwiftLint not installed, download it from https://github.com/realm/SwiftLint"
            fi
        - ProjLint: |
            if which projlint > /dev/null; then
                projlint lint
            else
                echo "warning: ProjLint not installed, download it from https://github.com/JamitLabs/ProjLint"
            fi
        - Carthage: /usr/local/bin/carthage copy-frameworks\n

A new rule that allows to compare a files content to a template file. Multiple template systems could be supported, also one-to-one compare should be possible. The template file could be within a .projlint/FileContentTemplate folder in the same project, in a different path on the computer (for shared templates) or it could even be a web link to a file hosted on GitHub.

The violation should mark the lines which differ or even generate a diff.

Rules should be testable very easily, thus having a preconfigured structure on how to ensure there are triggering and non-triggering examples is very important. This should include different sets of configurations.

• For showing the errors on Xcode, the printed paths should be absolute and not contain . or .. paths.

• The directory parameter in the violations(in directory: URL) is not being used in most cases. The reason for such thing is that the URL(fileURLWithPath: relativePath) function is used to convert a String to a URL. Such initializer, when the path is relative, automatically (and silently) sets the base directory to currentDirectoryPath, leading to an absolute path equal to:

  URL(fileURLWithPath: relativePath) = currentDirectoryPath + relativePath
  

  Seems that this is wrong: the path should be relative to the directory parameter. Thus, function URL(fileURLWithPath: relativePath, relativeTo: directory) should be used (only available from .macOS(.v10_11)).

  The reason this problem has not been detected in the tests is because the path property in the Resource object was always returning an absolute path.
  The reason this problem has not been detected in production is because the currentDirectoryPath is the directory where the .projlint.yml lives, as there is no possibility to specify a custom path for it.

Similar to this document on SwiftLint, ProjLint should have a starting point for contributors with explanations what to conform to in order to introduce a new rule. Also it could include a checklist of actions to take before a new rule can be merged:

• Make sure SwiftLint and ProjLint are both installed and passing.
• Make sure to write extensive tests for your new rule.
• Document rule in Rules.md including options and example config(s).
• Add Changelog entry under section "Added".

For the rule file_content_template there should be wildcard-matchers that can be specified in the template where the compared file can have whatever type the wilcard is. This can be done by using a Regex where in place of the wildcard there is a given regex. The wildcards and corresponding regexes could be:

The usage in a Template could be like this:

- Foo
{{ wildcard.list.string }}
- Bar

Currently the subcommand correct is a stub but not implemented. It should be implemented with some rules implementing the correction protocol(s). Rules declared as correctable should be automatically supported by the correct subcommand. A default bool option named correct could be introduced.

Configure a CI service to mark Pull Requests with errors if any of the following fail:

• Building
• Tests
• SwiftLint
• ProjLint

There should be example configuration managed by the community to get started quickly like for the following type of projects:

• Open Source Swift Framework
• Open Source Swift Tool
• iOS Project
• Android Project
• Rails App

More examples can be added by the community later on.

Currently when adding new tests to the project they are not run on Linux servers. A similar approach like in SwiftLint could be used to generate the contents of LinuxMain.swift automatically by analyzing the Tests directory.

Show warnings & errors right within Xcode. This should be configurable via default_options which can be overridden in any rule. The configuration could be named show_issues_in_xcode and be a simple boolean option. In addition to true or false there could also be a new case named always_warning which would even show errors as a warning.

When turned on, errors would be shown as errors and warnings as warnings right within Xcode.

A rule that allows to check that files at specific paths match or not-match given regex(es).

A rule that allows to specify how the project navigator structure should look like. This will allow to check the existence and order of folders and files. Also it can be used to specify that a specific folders contents or even entire substructure should be sorted by name or type or both. An example configuration could look something like this:

- rules:
  - xcode_project_navigator:
      project: {{project_name}}.xcodeproj
      sorted: true
      inner_group_order:
        - [interfaces, code_files] # Storyboards & XIB files, Code are mixed & sorted together
        - assets
        - strings
        - others
        - folders
      structure:
        - App:
            - Sources:
                - AppDelegate.swift
                - Globals:
                    - Extensions
            - Resources:
                - Colors.xcassets
                - Images.xcassets
                - Localizable.strings
                - Fonts
            - SuportingFiles:
                - LaunchScreen.storyboard
                - Info.plist
            - Generated:
                - SwiftGen
        - Tests:
            - Sources:
            - Resources:
            - SupportingFiles:
                - Info.plist
        - UITests:
            - Sources:
            - Resources:
            - SupportingFiles:
                - Info.plist
        - Extensions:
        - RootFiles:
            - beak.swift
            - .projlint.yml
            - .swiftlint.yml
            - Cartfile
            - Cartfile.ignore
            - Cartfile.private
            - Cartfile.resolved
            - SwiftGen-Colors.stencil
        - Frameworks:
            - Carthage:
                - App
                - Tests
            - Local:
                - App
                - Tests
        - Products

It should be possible to define for specific folders or specific type extensions, what the file name should be structured like. A config could look something like this:

rules:
  - file_name_regex:
      - directory_content_matching:
          Sources/Extensions: "\A[A-Z]\S+Extension\.swift"
      - directory_content_not_matching:
          Sources/SupportingFiles: "\A.*\.swift\z"
      - type_extension_matching:
          swift: "\A[A-Z]\S+\.swift\z"
          plist: "\A[A-Z]\S+.plist\z"

There should be a way to specify shared variables within the configuration file which can be referenced in all String option entries (like paths or regexes). The structure might look like the following:

shared_variables:
  project_name: MyProject
  main_scheme: MyApp

Then a String can use this variable with something like this:

rules:
  - file_existence:
      existing_paths:
        - {{project_name}}.xcproj/project.pbxproj

At the moment the printed errors are not very informative, and is impossible to find the offending line. For example:

/../../../ExampleApp/ExampleApp/Resources/en.lproj/Localizable.strings:-1: ProjLint:  File Content Regex Violation – Content matched regex 'Regex<"\n"(?!((([A-Z][a-z ]*)" = "\3")|(L\.[a-z][a-zA-Z]+" = ".+"));)">' where it shouldn't.

It will be very helpful if the error shows the offending line.

This issue seems to be also related to #29