New parser: file resources

[mgray88]

Add a new parser which allows accessing any other specified files that need to be accessed from the bundle, usually with Bundle.main.url(forResource:withExtension:) and the like.

• I've started my branch from the develop branch (gitflow)
  • And I've selected develop as the "base" branch for this Pull Request I'm about to create
• I've added an entry in the CHANGELOG.md file to explain my changes and credit myself
  (or added #trivial to the PR title if I think it doesn't warrant a mention in the CHANGELOG)
  • Add the entry in the appropriate section (Bug Fix / New Feature / Breaking Change / Internal Change)
  • Add a period and 2 spaces at the end of your short entry description
  • Add links to your GitHub profile to credit yourself and to the related PR and issue after your description

---

Fixes #665, fixes #637, fixes #496, fixes #284, fixes #146, fixes #109.

[AliSoftware]

Hello @mgray88 and thanks for the draft PR!

I know it's only a draft for now, but:

• Could you please add a description as to what this PR does?
• It seems to be an implementation of [Feature] General file resources from bundle #665 – which you've referenced in the title, tho honestly I missed it at first – but mentioning it in the PR description helps having GitHub cross-link the PR and issue. You might also want to cross-reference Add file names generator (nibs, plists, etc) #284.

Thx! 🙂

[mgray88]

I'm running into the issue again where swiftlint is ignoring the //swiftlint:disable all at the top of my Generated Fixtures files. The linter output shows it linting the other generated files and successfully ignoring them. However it reaches the files I've added, and spits out file_header violations

[AliSoftware]

I can take a look tomorrow (I'm on my phone rn) to check if it's indeed what I think it is, but it could be expected. Because we have a somewhat special setup for linting our template files

Basically the way our linting script is set up on SwiftGen for the generated files in fixtures is that it intentionally removes the // swiftlint:disable all from the generated files before linting them. The goal of that is so that:

1. We, as contributors and creators of templates that are gonna ship with SwiftGen, want to ensure we ship templates that respect some linter rules we set for ourselves. Like we want the templates that we ship with SwiftGen to be consistent in their indentation, use of spaces around colons, etc, and pass the swiftlint.yml rules of the SwiftGen repo itself
2. But, for people using those templates in their projects, they might be using a different set of SwiftLint rules, etc, so even if they wouldn't trigger our rules they could still trigger the user's rules. Which is why all our templates include // swiftlint:disable:all once shipped and used by end users

I can get how this could be confusing and seem convoluted 😅 (we should definitively document that special setup in our CONTRIBUTING.md btw…). But that's the way we found to both disable swiftlint for end users of our templates while still be able to lint those templates for ourselves when working on SwiftGen — to ensure they are at least consistent with our style rules.

[EDIT] If you're curious, here is where the magic happens

[mgray88]

Gotcha. That all makes sense. I did notice the Scripts/SwiftLint.sh but it doesn't appear to discriminate based on folder/file names and just globs everything under Tests/Fixtures/Generated

[AliSoftware]

Yes it does force-lint (= remove disable:all before linting) everything under Tests/Fixtures/Generated but that's expected as that's where the fixtures generated by bundled templates are expected to be and that's what we want to lint.

Did you use the "Generate Outputs" Xcode scheme to auto-generate those fixtures from the templates (so that they can then be used by our unit tests)? Or did you write them by hand?

[SwiftGen-Eve]

	1 Warning
⚠️	Big PR

Hey 👋 I'm Eve, the friendly bot watching over SwiftGen 🤖

Thanks a lot for your contribution!

---

Seems like everything is in order 👍 You did a good job here! 🤝

Generated by 🚫 Danger

[mgray88]

Can anyone provide insight on why the lint task is failing? All it says is Danger has failed this build but all the lint step succeeded with 0 violations. Oh wait, Danger is failing because of the CHANGELOG isn't it?

Also there is no output for the failing test. The tests build and run fine on my computer so I'm not sure how to fix them on CI It initially had a failed run, but now it doesn't?

[mgray88]

@AliSoftware @djbe Will the cli additions need to be included with this PR or a new one? I'm also working on writing up some of the documentation

[djbe]

I've implemented the filter changes I mentioned in one of my previous review comments, it was really needed (I think) because the old code would just go through all the files/children of a folder without applying the filter anymore. Does this matter for basic extension regexes? No. But it might've mattered for more complex cases 🤷

As discussed I've applied the other changes as well. The end result is that this parser is kind of like a mix of the Fonts and Strings parsers.

Future PRs could add extra accessors/methods depending on the file mime-type, a bit like the XCAssets templates right now.

[mgray88]

@djbe I'm glad you were able to get these changes in, work's been hectic on my end. I think it definitely looks much better. I did notice a few things in the new swift4 docs that still referenced swift5, or other files they were probably copied from

[4brunu]

Any news on this? Looking forward to it 🙂