Skip to content
This repository was archived by the owner on Jan 7, 2025. It is now read-only.

add initial rulesets #4

Merged
merged 2 commits into from
Apr 27, 2021
Merged

add initial rulesets #4

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
40a2778
initial rulesets
pq Apr 27, 2021
d22794b
+ include
pq Apr 27, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 28 additions & 0 deletions lib/core.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
linter:
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we want the file path here to be /lib/dart/core.yaml so that we could also have a /lib/flutter/core.yaml ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Interesting. Scoping has some other nice benefits too.

@goderbauer @devoncarew : wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

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

TBH I think that supporting frameworks in this package will be challenging. Once we add one there's no reason we shouldn't then support more; changes here will be tightly versioned together even though the frameworks will be logically unrelated.

I'd optimize for the 'dart' case here, and just have the two main files in the top level of the lib/ directory.

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'd optimize for the 'dart' case here,

I guess if we leave it as is, we could always add directories for frameworks (if we added them). So we might have something like:

lib/
 core.yaml
 recommend.yaml
 framework_1/
   core.yaml
   recommend.yaml
 framework_2/
   core.yaml
 ...

What do we think about flutter in the short term? Top-level, nested or somewhere else?

Copy link
Contributor

Choose a reason for hiding this comment

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

FWIW, I don't think we will have multiple lint sets for flutter. There'll just be a flutter.yaml set,

rules:
- avoid_empty_else
- avoid_relative_lib_imports
- avoid_shadowing_type_parameters
- avoid_types_as_parameter_names
- await_only_futures
- camel_case_extensions
- camel_case_types
- curly_braces_in_flow_control_structures
- empty_catches
- file_names
- hash_and_equals
- iterable_contains_unrelated_type
- list_remove_unrelated_type
- no_duplicate_case_values
- non_constant_identifier_names
- package_prefixed_library_names
- prefer_generic_function_type_aliases
- prefer_is_empty
- prefer_is_not_empty
- prefer_iterable_whereType
- prefer_typing_uninitialized_variables
- provide_deprecation_message
- unnecessary_overrides
- unrelated_type_equality_checks
- valid_regexps
- void_checks
52 changes: 52 additions & 0 deletions lib/recommend.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
include: package:lints/core.yaml

linter:
rules:
- always_require_non_null_named_parameters
- annotate_overrides
- avoid_function_literals_in_foreach_calls
- avoid_init_to_null
- avoid_null_checks_in_equality_operators
- avoid_renaming_method_parameters
- avoid_return_types_on_setters
- avoid_returning_null_for_void
- avoid_single_cascade_in_expression_statements
- constant_identifier_names
- control_flow_in_finally
- empty_constructor_bodies
- empty_statements
- exhaustive_cases
- implementation_imports
- library_names
- library_prefixes
- null_closures
- overridden_fields
- package_names
- prefer_adjacent_string_concatenation
- prefer_collection_literals
- prefer_conditional_assignment
- prefer_contains
- prefer_equal_for_default_values
- prefer_final_fields
- prefer_for_elements_to_map_fromIterable
- prefer_function_declarations_over_variables
- prefer_if_null_operators
- prefer_initializing_formals
- prefer_inlined_adds
- prefer_is_not_operator
- prefer_null_aware_operators
- prefer_spread_collections
- prefer_void_to_null
- recursive_getters
- slash_for_doc_comments
- type_init_formals
- unnecessary_brace_in_string_interps
- unnecessary_const
- unnecessary_getters_setters
- unnecessary_new
- unnecessary_null_in_if_null_operators
- unnecessary_string_escapes
- unnecessary_string_interpolations
- unnecessary_this
- use_function_type_syntax_for_parameters
- use_rethrow_when_possible