Skip to content
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

Changes to creation of rule set #154

Merged
merged 4 commits into from
May 20, 2024

Conversation

stoivo
Copy link
Contributor

@stoivo stoivo commented May 16, 2024

I am working on solving #128. To get to know the code I did some changed which I think makes it overall better.

I could try not to change anything else that what I absolutely have to but I think we will come better out of it if we make some more changes. Could you take a look at this changes and give me some pointer if you like this or not?

@@ -13,7 +13,11 @@ Rake::TestTask.new do |test|
test.verbose = true
end

RuboCop::RakeTask.new
RuboCop::RakeTask.new do |t|
# allow you to run "$ rake rubocop -a" to autofix
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

prefer something like

RuboCop::RakeTask.new :fmt do |t|
  t.options << '-A'
end

or a rubocop:reformat etc, but might refactor that later

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't default to -A and it is unsafe.

RuboCop::RakeTask.new created three tasks.

$ rake -T
rake rubocop                  # Run RuboCop
rake rubocop:autocorrect      # Autocorrect RuboCop offenses (only when it's safe)
rake rubocop:autocorrect_all  # Autocorrect RuboCop offenses (safe and unsafe)

So I could use rake rubocop:autocorrect to format my code but. The way I work is that I make some changed to the code without thinking to much about style, then run specs and I ran the specs with rake (the default task) and in those cases it would stop at rubocop. In anouther project I added these two options so I could run rake -a. I could also change to run rake test.

So maybe I should just drop this change

# +filename+ can be a string or uri pointing to the file or url location.
# +offset+ should be Range object representing the start and end byte locations where the rule was found in the file.
def add_rule!(*args, selectors: nil, block: nil, filename: nil, offset: nil, media_types: :all) # rubocop:disable Metrics/ParameterLists
if args.any?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ideally not support args at all without deprecated: true being set, but still a good step forward

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm not understanding what your suggesting.
It would be a breaking change it we now require deprecated: true to pass keyword arguments. If somebody are doing the change to add the that keyword argument why don't they change all to keywords arguments.

Comment on lines +259 to +263
when 4
filename, offset, selectors, block = args
when 5
filename, offset, selectors, block, specificity = args
else
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need to add this when we only supported selectors, block, specificity before ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because I removed OffsetAwareRuleSet. I was thinking we could have less conditionals if we merge those

lib/css_parser/rule_set.rb Outdated Show resolved Hide resolved
lib/css_parser/rule_set.rb Outdated Show resolved Hide resolved
Copy link
Contributor

@grosser grosser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about we use the v2 branch (I just created) and merge these PRs there and then don't have any deprecation/warning ?

(nobody else works on the repo atm so should not have merge conflicts and we can have a upgrade readme section with all the changes)

@grosser
Copy link
Contributor

grosser commented May 16, 2024

rubocop failed

Deprecation message look like:

	/Users/simon/Downloads/css_parser/test/test_css_parser_basic.rb:75:
	 warning: [DEPRECATION] positional arguments are deprecated use
	 keyword instead.
@stoivo
Copy link
Contributor Author

stoivo commented May 20, 2024

I think we can patch 1.x to have deprecation for changed to public API, and create update v2 branch without those. Probably a good idea to change to version 2 when we replace the css parser

@stoivo stoivo force-pushed the st-refactor-creation-of-rule-set branch from 59f0fa5 to 219d43e Compare May 20, 2024 08:38
@grosser
Copy link
Contributor

grosser commented May 20, 2024

I'm not a fan of deprecations and the extra complexity they bring, but this looks most well though out to me so 👍

@grosser grosser merged commit 6b3cca7 into premailer:master May 20, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants