Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/sparksp/elm-review-name-visitor
elm-review module to visit each name in a module
https://github.com/sparksp/elm-review-name-visitor
elm elm-review
Last synced: 8 days ago
JSON representation
elm-review module to visit each name in a module
- Host: GitHub
- URL: https://github.com/sparksp/elm-review-name-visitor
- Owner: sparksp
- License: mit
- Created: 2020-05-17T11:15:59.000Z (over 4 years ago)
- Default Branch: master
- Last Pushed: 2024-08-11T06:40:10.000Z (3 months ago)
- Last Synced: 2024-08-11T07:39:59.276Z (3 months ago)
- Topics: elm, elm-review
- Language: Elm
- Size: 440 KB
- Stars: 2
- Watchers: 3
- Forks: 1
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# review-name-visitor
Current version: `0.3.1`.
![elm-review 2.0](https://img.shields.io/badge/elm--review-2.0-%231293D8)
![elm 0.19](https://img.shields.io/badge/elm-0.19-%231293D8)
![Tests](https://github.com/sparksp/elm-review-name-visitor/workflows/Tests/badge.svg)Visit each name in the module. A "name" is a `Node ( ModuleName, String )` and represents a value or type reference. Here are some examples:
- `Json.Encode.Value` -> `( [ "Json", "Encode" ], "Value" )`
- `Html.Attributes.class` -> `( [ "Html", "Attributes" ], "class" )`
- `Page` -> `( [], "Page" )`
- `view` -> `( [], "view" )`These can appear in many places throughout declarations and expressions, and picking them out each time is a lot of work. Instead of writing 1000 lines of code and tests each time, you can write one `nameVisitor` and plug it straight into your module schema, or separate `valueVisitor` and `typeVisitor`s.
## Documentation
### One Name Visitor
This will apply the `nameVisitor` to every value and type in the module, you will get no information about whether the name is a value or type.
```elm
rule : Rule
rule =
Rule.newModuleRuleSchema "NoInconsistentAliases" initialContext
|> NameVisitor.withNameVisitor nameVisitor
|> Rule.fromModuleRuleSchemanameVisitor : Node ( ModuleName, String ) -> context -> ( List (Error {}), context )
nameVisitor node context =
-- Do what you want with the name
( [], context )
```### Separate Value and Type Visitors
This will apply the `valueVisitor` to every value and the `typeVisitor` to every type in the module.
```elm
rule : Rule
rule =
Rule.newModuleRuleSchema "NoInconsistentAliases" initialContext
|> NameVisitor.withValueAndTypeVisitors
{ valueVisitor = valueVisitor
, typeVisitor = typeVisitor
}
|> Rule.fromModuleRuleSchemavalueVisitor : Node ( ModuleName, String ) -> context -> ( List (Error {}), context )
valueVisitor node context =
-- Do what you want with the value
( [], context )typeVisitor : Node ( ModuleName, String ) -> context -> ( List (Error {}), context )
typeVisitor node context =
-- Do what you want with the type
( [], context )
```### Visit Values Only
This will apply the `valueVisitor` to every value in the module, and ignore any types.
```elm
rule : Rule
rule =
Rule.newModuleRuleSchema "NoInconsistentAliases" initialContext
|> NameVisitor.withValueVisitor valueVisitor
|> Rule.fromModuleRuleSchemavalueVisitor : Node ( ModuleName, String ) -> context -> ( List (Error {}), context )
valueVisitor node context =
-- Do what you want with the value
( [], context )
```### Visit Types Only
This will apply the `typeVisitor` to every type in the module, and ignore any values.
```elm
rule : Rule
rule =
Rule.newModuleRuleSchema "NoInconsistentAliases" initialContext
|> NameVisitor.withTypeVisitor typeVisitor
|> Rule.fromModuleRuleSchematypeVisitor : Node ( ModuleName, String ) -> context -> ( List (Error {}), context )
typeVisitor node context =
-- Do what you want with the type
( [], context )
```## Scope
This makes no attempt to resolve module names from imports, it just returns what's written in the code. It would be trivial to connect [elm-review-scope] with the name visitor if you want to do this.
[elm-review-scope]: http://github.com/jfmengels/elm-review-scope/
## Why this is not published as an Elm package
If this module gets published as a stand-alone package, and several rule packages start depending on it, then people may get stuck with old versions of packages until all packages catch up with any changes here. This is due to Elm not allowing duplicate dependencies with different major versions when building applications.
If the module gets exposed as part of a review package, then if another package does the same thing or the user has copied this package too for their own custom rules, then it is possible to get into module naming conflicts, which is not ideal.
I would really like you to **NOT publish this as a package**, and to **NOT expose this module** as part of your package. It is okay to publish a package using and containing this module, but without exposing it.