New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow configuration of 'discouraged_object_literal' rule #2439

Closed
shagedorn opened this Issue Oct 15, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@shagedorn
Copy link

shagedorn commented Oct 15, 2018

New Issue Checklist

New rule request

Similar to the object_literal rule, I'd like to have configurability for the inverse discouraged_object_literal rule, to enforce literals for some objects, and enforce the opposite for others.

Currently, only enforcing literals can be configured, but you cannot selectively discourage the others.

The main motivation comes from Xcode 10's terrible image literal support (you can basically only use them by dragging from the media library, and it's very hard to see or edit the raw image names in Xcode, nor do you see a preview).

Our goal is to enforce literals for all objects (currently that means colors), except for images, where we want to enforce non-literal syntax.

The relevant part of our config file would look like this:

opt_in_rules:
  - discouraged_object_literal
  - object_literal

# this part doesn't work yet
discouraged_object_literal:
  color_literal: false

# this already works
object_literal:
  image_literal: false

I would assume the existing ObjectLiteralConfiguration can be used for both rules.

Unless I'm missing something and this option shouldn't be implemented after all, I would volunteer to look into the code myself.

@marcelofabri

This comment has been minimized.

Copy link
Collaborator

marcelofabri commented Oct 17, 2018

A PR would be welcome!

@shagedorn

This comment has been minimized.

Copy link

shagedorn commented Dec 24, 2018

Thank you 🎄

kimdv pushed a commit to kimdv/SwiftLint that referenced this issue Jan 6, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment