Getting started with elm-review

Getting started with elm-review

elm-review lets you extend guarantees that Elm provides before running your code, by inspecting your project with custom rules that you write in pure Elm!

PublishedApril 8, 2020

Episode#3

Transcript

Hello Jeroen! Hello Dillon! How are you doing today? I'm doing very well, how are you?

I'm doing pretty good, I'm curious to hear your thoughts on this topic because

I think you have a lot to say. What are we talking about? Today we're

talking about Elm Review and the first episode we did was on Elm pages, that

was your baby. Yes. This is my baby. Yes, I think there will be a lot of words

coming from you today. Yeah, I'm excited to talk about this. Yes, I'm excited to

learn about it. Yeah, so okay, Elm Review, I believe it used to be called ElmLint.

You had a package called ElmLint before and this is like a new incarnation of

that. Basically, so I spent a lot of time working on it when it was called ElmLint

and right before publishing it, releasing it, I renamed it Elm Review. So I never

really announced it as ElmLint. I did a talk about it in Elm Paris, the meetup,

in 2017. So it's a very old project, it's dated before Elm Analyze, but it's never

been released as ElmLint officially, although I did publish some packages with

a name. So if you see those, ignore them. I can't publish them, unfortunately.

So people are probably familiar with the concept of linting and with linters, so

you want to give maybe a little bit of the background of why you

chose the term review instead of lint. Evan came to talk to me about it.

It's a good reason. Yeah, I sent him the link to my blog post before I released

it. I was thinking, hey, what do you think of this? Do you think this is a good idea

for the Elm ecosystem? And he said, yeah, I think it's okay. I don't remember

exactly the words he said, I'm just imagining. The main thing he said to me

was like, are you sure you really want to call it ElmLint? You should use some of

those quotes from Evan on the package documentation site, just like, yeah, I

think it's okay. Yeah, well, I don't have the course anymore because it's on Slack.

That was six months ago, so they're lost forever. Right, but there's this sort of

literal naming concept in the Elm community, right? So Evan was trying

to think about, like, what is linting anyway? What does

your package really do? Yeah, exactly, and I actually didn't know what linting is. I

was just calling it a linter because that's what people call these kind of

tools. So I looked it up a little bit because lint was not in my English

vocabulary, and it turns out it's removing pieces of dust from clothing, so

it's basically cleaning it. And that's kind of what most linters do. They try to

polish your code, make you adapt to a certain code style, and that is not what

Elm Review is about. So I decided to rename it. I had some project names to

choose from, and Elm Review started to sound good to me, and now I'm very happy

with the choice. Yeah, I like it a lot too. It seems very clear, and you know, maybe

for somebody who's familiar with the term linting, that might seem easy to

understand at first, but so does Revu, and to someone who's not familiar with

linting, Revu makes a lot of sense too. Yeah, linting, you have to know the term.

Someone needs to have explained to you what the linter is, but my colleagues

still call it a linter. So it's hard to get rid of the name, like, oh, Elm Review!

Well, it's just kind of a linter, isn't it? Yeah, well, in a way it is.

You can do linting with it, but I am to make it something a bit bigger.

Right, okay, so let's get into that. So let's kind of get into a

definition of what Elm Review does. What is it, besides this sort of vague

notion of a linter, what exactly is it? Yeah, so Elm Review is a static

analysis tool for Elm, written in Elm. So static analysis just means we're gonna

look at your code, and we're gonna detect patterns, and then do something about it.

In our case, we're going to report some patterns that we do not

want to stay in the code. For instance, something that most linters do is say,

hey, this variable is not used, remove it. Or in some languages like JavaScript,

remove some features or forbid some features, like don't use pattern

matching, like don't use switch case, don't use goto, things like that.

Things that you do not want to see in your code. Sometimes it's as simple as just

forbidding patterns, sometimes it's forbidding a pattern in a certain

context, like don't use switch case with a number, for instance.

Right, it's an interesting problem of how do you identify looking at the

syntax, statically analyzing the code, how do you identify potential problems or

red flags or things that basically could indicate a code smell, right? That you're

kind of trying to detect a code smell and use this automated tool to put it in

front of a human being who can look at it and say, oh yeah, what do you want to

do about this code smell? How do you want to change this?

What are some examples that you think are really valuable or some

cool examples that you've seen? I know you've been working with some people on

some rules they've been building for Elm Review. What are some cool examples?

That was mostly me, unfortunately. Well I know, I saw someone was using it, maybe

this is sort of like a beta testing phase, but somebody was playing around

with an RGB rule to see if something is within a certain range.

Yeah, Ruf, I don't remember what he was. Yeah, Ruf. Rinar. Okay, yeah, he built it

himself and then he showed it and then I gave him some comments, but he did it on

his own. That was pretty cool. So what he did was publish a package which

looks at function calls that are called RGB or RGB 255. So those are the

functions that create colors in Elm UI. This rule just looks at what arguments

are given to it and then it checks whether those are in the proper

boundaries. So for RGB it checks whether the value is between 0 and 1 and for RGB

255 between 0 and 255. Because what happens if you call RGB with

minus 1? That doesn't make sense, that would probably be a bug and we don't

want that. And the RGB function is not strict enough to limit the values that

you give it. Do you know if his rule checked that it had to be a literal

value rather than a parameter? It only checks for literal values. Right, right.

You could try to evaluate the variable or function name, function call, but that's

something that is pretty hard with static analysis. At some point it will

get very hard and sometimes it's just too dynamic and you can't say anything

about it. Yeah, I mean sometimes it's coming from user input and there's no

literal value in the code to look at. So why don't you tell us a little bit about

like let's say we're building this RGB range checker. What does that look like

writing that with Elm review? So you said it's a review tool that's built in

Elm for Elm. Yeah. How do you build it in Elm? What does that look like? So Elm

review is both a CLI and a package. So the CLI runs the review and shows you

the errors. We've got the package which gives you some very nice APIs to work

with to create rules, what I call a rule with other knitters call that checks or

yeah checks or rules. So you got a package which creates those rules and

basically what it works with is an AST, so an abstract syntax tree. And what the

package does for you is it lets you visit every node of the tree and then

lets you do something with it. So either report a pattern like you notice

something that is wrong so you put an error and that will be shown to the user

or you record some data that you might use for to report errors later or to not

report errors later. So basically when you create a rule you say I want to

visit this kind of nodes, I want to visit imports, I want to visit

expressions, I want to visit declarations and based on that, based on

what you see in there, you're going to say hey this this does not look good

report an error. So for instance if we do the RGB rule we're going to look at

expressions, specifically we're going to look at function calls expressions where

the function name is called RGB or RGB 255 and then we're going to look at the

arguments and see if they are literal integers or literal floats and if they

do not match, if they do not fit in the correct range then report errors. So

that's basically what Unreview allows you to do. Right and so to paint a

picture for people listening, you know we said at the top that this is built in

pure Elm, you build the rules in pure Elm. Yes. Let's paint a picture a little bit

of what that looks like. So you say you can visit these different nodes in

the AST of your code base. So you're going to have some sort of function

that you call to say I'm defining this rule and then you get a parameter

which is like each node that you're visiting in the AST. Right and then

you're doing like a case statement that says is this a function call, is that

right? Yeah basically. And then if it's a function call then you get okay well

which function is it invoking like what's the module name and the function

name? Yes. And then what are the parameters that are being passed and

those parameters are expressions and then you can check is the expression of

type literal int? Yes. So that's all it is right? That's all it is. In this one

this is simple. This is a simple one right but it you have the full power

of doing whatever static code analysis you could imagine through this API. So

you're exposing sort of a platform for building your own customized rules.

Exactly. And you completely have the power at your fingertips of analyzing the entire

AST in Pure Elm which is really really fun. Yeah I have a lot of fun running

all those rules. Yeah so maybe this is a good time to sort of talk about Elm

analyze and contrast these two approaches. You want to talk a little bit

about what distinguishes the the different like philosophies or approaches

of these tools? Yeah so Elm analyzes at the moment the de facto standard for

static analysis in Elm. So the way it works is it gives you a set of checks

because it calls the checks but it's the same thing as a as what I call a rule

and they are all opt out so you get a full set of those to start with and it

just goes through your AST and reports the problems. So the thing with Elm

analyze is that you cannot customize those rules or very very little. You can

disable it and that's pretty much it. And the idea is that they want to enforce

high quality Elm code so that's what they try to do so they detect unused

variables and use imports. They detect ways you can simplify your expressions

like concatenating two lists so you could if it's if they're all literals

then you can just create one list. But in their contribution guidelines they say

that they do not want to be able to customize the rules like they do in

Iceland and that is exactly what Elm review wants you to do. When I write Elm

review I want you to be able to customize your rules. I want you to

create your own rules because I think that's where the power of static

analysis is. So in the JavaScript world where I come from you had jsLint, jsHint

and later came eslint. The difference between all these is that eslint

allowed you to create your own custom rules and that created a whole huge

ecosystem of rules maybe too big in their case and they made it

now the de facto standard. And the reason why I think that's important

is because the most interesting rules are not about code qualities, the ones

that you want to make for your own team. One thing you can do is enforce the

conventions of your team. Instead of saying hey we have a mockdown file here

that explains how we structure our Elm code, just enforce it. So you can

create an Elm review rule that does exactly what that guideline would

say and maybe with some auto fixes or very helpful error messages that tell

you hey we do not do this this way in our project because this and that reason.

You should try this and that to make it work the way we want to.

Right, so I've had the experience with Elm analyze. I've gotten a lot of

value from throwing that into projects before but also I've found that

sometimes the rules don't do exactly what I want. So one example of

that is I can't remember if it's unused symbols or something like that

but sometimes I'll find I'll import something. What I basically want is I

want to import something the same way every time I use it. So if I say import

dict exposing dict or if I say like import HTML dot attributes as adder

exposing attribute. I'm not sure if attribute is in HTML. I guess it's in

HTML but you get the idea right? Every time I import HTML I

want to expose attributes. I might not use it in a particular file but I

want it to be exposed for when I do use it. That's just what I want. I want

my import HTML exposing attributes to look the same in every single module.

So this unused symbol rule doesn't quite get that and I'm like no this is how I

want this code to look and so there will be this sort of mix of some things that

it finds that I'm like oh good catch I don't want to be doing that and then

there are some places where it's just pestering me about something that I'd

like to be able to tell it exactly what I want it to do. So I guess

that's your thinking here is that I can teach it the way that I want to write my

import statements. Yeah you definitely could. I also think there are plenty

plenty of cases where you do not want to enforce something. So maybe you do not

want a rule for that. Just tell people what to do because the thing is what I

noticed is that a lot of times when you enforce something that people don't like

they will try to disable it. Like in ESLinted they do that with a comment. You

will see disabling comments all over the place or they will try to find a

workaround which often makes the things worse. So in this case I think it would

be fine. Yeah that makes sense. I've had this thought before actually if I could

go down this path a little bit more of this particular idea of like having a

standardized way of importing things. I've thought it would be cool if there

was like a configurable way to say okay this is how I import HTML attributes.

Like I always want if I import that at all then I want it to be import HTML dot

attributes as adder. Yeah. Because I don't want to have it like in some places it's

imported as HTML dot attributes and some places it's as adder and that can be

confusing sometimes because you're going back and forth between different modules

in your code base and they're imported different ways. It becomes confusing and

so I've thought it would be cool if there was a way of enforcing in the

entire code base here's a certain set of import statements that should be aliased.

You should import as this and you should always expose this in addition to

whatever other specific things perhaps you expose or maybe you want to enforce

that or whatever but that seems like something that could be an interesting

tool and since it's just Elm code so since the rules are just pure Elm

code you could make it configurable by passing in your specific configuration

and saying these are my imports these are the module names and these are what

I expect them to be aliased to so I could imagine that could be a pretty

cool rule that you could share with people and let them define their own

list of import aliases. Yeah exactly I was actually thinking of doing that in

my workplace. Oh cool. Like for instance sometimes we import JSON encode as

E and sometimes as encode and sometimes without an alias and I think would be

just nicer to enforce having the same one everywhere. Very cool. So is there a

way currently in Elm review to apply fixes? I think there might be some

functionality like that is that right? Yeah there is. So in Elm review v1 you

can only apply fixes one by one so you tell the CLI to apply fixes and

it will prompt you with hey this is the error this is my suggestion do you want

to accept it do you not and then if you do then it gets it fixes it applies Elm

formats all the time that's a design choice I want people to use Elm formats

that might be wrong but my choice and in Elm review v2 you also have a fix all so

you can just fix all the errors and then have a giant diff and it prompts. Is it

the errors of a particular type or just all errors? All the errors that provide a

fix. Okay. And that is not something you always want to do. There's something

that detailed in my documentation. You basically want it when it's you can fix

it always when you know how to do a proper fix and when it's it doesn't

bring anything to the user and it will not surprise them. Right so do you think

that would be a reasonable place to apply that rule to say hey if you're

importing JSON dot encode as E actually the way we do that is encode. Would that

be a reasonable place to apply an automated rule perhaps in a code base?

Well yeah it would but the thing is you would need to change every call to E dot

something to encode so if you do that then it's all good to me. So you and

could you do that? Yeah I think you could. Because you get access to the syntax tree

and you can define a way to transform that syntax tree and it will output that

as the fix? No the fix is a bit lower primitive you basically just play with

ranges so remove characters insert characters or replace characters.

Interesting. With the range like start and with the row in a column. Yeah I

could have chosen to do it with an AST but that would have been more

complicated and that hasn't been my focus yet. Right. Maybe we could do it but it

does makes a lot of things much harder so I think it's nice to have at least

this primitive and for now it's it's worked alright so I haven't needed to

do anything harder and basically everywhere you see E dot something and you

know that it's the E module not something else that ends with an E you

replace it with encode dot for instance and that would be it. Right yeah that

seems that seems pretty doable very cool so if somebody wants to get started with

this how do they dive in? To get started with Elm Review you basically want to

add a review configuration to your project so as I mentioned before there

is a CLI so you do Elm Review init and it will create a new application inside

your project we do that so that the review codes your your rules and the

review dependencies so all the packages that contain rules that you might want

to add to your configuration that they're separate from your package or

application so the init creates the project so an Elm JSON and a review config

dot Elm file that one comes empty by default there are no rules enforced

there's also design choice that I made I don't want to enforce best practices

because I don't feel like I should tell people what to do so it comes empty and

then what you do is either you add packages that contain rules and use the

rules that are in there and you add them to review config or you write your own

rules and you add them to your review config so yeah I would start out with

Elm Review init and then adding some packages that like I wrote for instance

the ones that remove unused things or do a lot of simplifications. Right and just

to just to make it clear what you're saying is when you do Elm Review init

and you say it creates a separate app it's just creating a subdirectory which

the CLI is going to go into that subdirectory that review subdirectory or

whatever it's called yes and it's going to use the source folder in that

directory which is just an Elm code base it has an Elm dot JSON which lists the

dependencies for running the review rules yeah which are independent of the

dependencies for the main Elm projects that it's running the rules on. Exactly

yeah that's it. And then you just got another Elm code base within your main

Elm app for running the rules. No that you don't that's what the CLI does so

every time you run Elm Review it creates a new application it compiles an

application with your code with your dependencies and then it runs that one.

Right right but you you have this sort of folder that defines all of your

rules in pure Elm and you don't have to worry about the specifics of visiting

the files and those details the CLI takes care of that for you. Exactly yeah

yeah yeah cool yeah you have very little things to do on your own. Right.

Even just running your own rules there a lot of complexity has been removed for

you. So is there a good starting point to sort of copy paste as a starting point

to play around with creating your own rules? Not right now I'm probably gonna

do something before I release v2 because at the time that we record this it has

not been released yet hopefully in the next few days so hopefully by the time

you listen to this episode yeah probably gonna make something to make it easy for

people to copy paste because that's what people tell me a lot they don't want to

think about which rules to enable they just want to copy paste something which

I do not think is great but as long as they stay critical of the review rules

I'm fine with that. Yeah yeah you could have some sort of commented out set of

possibilities so people can see what the options are as a starting point and but

so if you want to define a custom rule sometimes that can be intimidating to

figure out just like the wiring for creating a custom rule but I guess it's

just calling a single function and then that creates a rule value. Yeah basically

yeah so I've got a lot of examples in the documentation so you basically can

just copy paste an example and add it to your review project your review

application and add it to your review config and that's it. So basically if

someone wanted to try out writing their own rule they should go to the projects

readme and then find an example rule and they can copy paste that to play around

with it. Yeah well to the review rule module but yeah basically. Right right

they should create a self contained module for their rules just as a good

practice of abstracting things away. Yeah I would always put it in a different

module yeah one rule one module. Right nice well are there are there any other

resources that people should know about for getting started? I would probably

say just the blog post about releasing version 1 and version 2 yeah that would

be it for if you want to get started. Wonderful. So I released Unreviewed

version 1 about six months ago and I'm ready to release v2 and there's

something that I really really wanted to get out and I'm very happy that I got

something pretty cool with it. It's the ability to look at whole projects for

when you analyze your project your code. So with most static analysis tools like

Elm Analyze and ESLint whenever you look you go through the AST so you do it one

file by one file so when you look at module A you go through the whole file

you report some errors and then when you're done you go through module B

and then you forget at that point you forget everything about module A even

if that was interesting to you so if module B imports module A you do not

know what happens in A so you lose a lot of information and that is a shame

because there's a lot of interesting information that you can get there

especially in Elm in JavaScript with ESLint that would be useful too but

sometimes just too complex to analyze. When you don't have type signatures

helping you navigate through it it's too much to manage. Yeah exactly and

handling all those details. Yeah and especially when things are too dynamic

that's when you just abandon hope. Because Elm is a static language it's

not just statically typed it's a static language so you know when you hit

compile you know the functions that will exist you know the top level values and

functions that you'll be working with and you can't just eval something and

then something comes into existence at the global scope. Yeah that makes it really

really nice to work with. As someone who wrote a lot of ESLint rules that was a

pain it was very frustrating to say oh well in this case we really can't know

just well. But with this version what I introduce is what I call project rules

which can look at the whole project so when you have finished visiting A you

can keep some information the information that you want and then when

you start to read going through module B then you can use the information from

module A. So would that be sort of like the difference between like a map or a

fold where if you map then you have to say okay take this value and turn it

into a new value whereas a fold you get to keep track of this accumulator where

you can store some running value that you get every time you visit a new thing

and you can add additional context into that? Yes yes that's a if you're very

familiar with maps and folds yes that's exactly how you can view this. There was

probably my initial implementation a map and now it's a fold that is true. So

what that opens up to is like detecting unused variables or unused exports

everywhere so if module A exposes a function well with when you can only

look at one file at a time you can't ever tell whether it's used or not and

you can't tell the user hey this is never used. With what I call project

rules you can you just go through the whole project and oh well it's never

used okay remove it report it and that opens just a whole lot of possibilities.

This is actually the reason why I didn't promote Unreview too much during

these last six months because every time I was thinking of a very cool rule to

demonstrate what you could do with Unreview I was like yeah as soon as you

need to get a value from another module or expose things well you can't tell.

So one example is for instance you know the problem where you have a list

of all the custom types of a type like if the custom type is A, B or C you want to list

with A, B and C for testing purposes or things like that. The solution people

usually go for is having a type check reminder like a case of which lists

all the cases which that does nothing with a comment that says hey now you

should add it to the list below. Well with Unreview you can just say hey we

know all the custom type constructors and in this list there are some missing

ones report it. I think it's very cool but if the type was defined in a

different module then you can't tell anything. Now you can. That's why I

was not promoting it. Yeah that makes sense it opens up a lot more use

cases I can imagine just having that contextual ability to define rules that

have context that they carry with them. So okay this is perhaps a tangent but

that makes me think of would it be possible to define a rule that auto

fixes that has an automated fix where you can say if you have an enum where an

enum is you know just a custom type that has no parameters for the type so you

have you know a fruit is an apple or an orange or a banana could you have an

auto fix that says a module that has that maybe there's a certain naming

convention for the custom type or something that it's like enum fruit or

something and then that module must define a to string and a from string and

maybe an all list which has all of the all of those enums mm hmm could you

define an elm review rule that checks that those to string from string and all

values and functions are defined and if they're not defined creates them for you

you could definitely do one that checks for them an auto fix yeah I guess you

could just have to handle the case where the functions already exists because you

don't you probably don't want to override them yeah you could hmm yeah

because that could be pretty powerful because at that point you have a

guarantee that if you in your build pipeline run elm review before you do a

production build then you can almost consider it a piece of the pipeline just

like the elm compiler where you know if you if you have something where your

types make impossible states impossible right then you don't have to check all

over the place that you're enforcing those constraints because you've done it

with a type and the elm compiler will catch it so your your production code

won't go live with those impossible states yeah and so if you have your elm

review rule and the elm review checks as part of your production build where the

production build will not go live unless these constraints are met then you could

guarantee that these enum values will always be up to date which is kind of

cool you could just build a review rule that just sort of extends the

guarantees of the elm compiler in a way yeah that's that's the whole point of a

lot of rules that you can do with them right yeah I'm not sure whether that

example would be fitting because how would you implement the to string like

what name do you give to the banana to the apple would it be uppercase like and

that's not those are not choices that you want elm review to do for you so

I could do it in my code base and I could just have that be my custom rule

that I define that right yeah if you have something very organized and you

exactly know exactly how to fix it sure go ahead right yeah it seems like you

could make some conventions like that I I'm also thinking about I mean elm

review gives you this essentially an elm project that you can run the CLI against

this source code for your elm review rules and I'm thinking like it could be

interesting to ship this as a part of other tools like for example elm graph

QL has you know it does this code generation like there's a feature in elm

graph QL that I've had a really hard time getting the developer experience

that I want for this feature the feature is custom scalars and I mean I think it's

I think it's a really strong feature actually I don't I don't think there are

any other graph QL tools out there that have this feature which is but I still

feel like the developer experience could be a lot stronger so the feature in a

nutshell is you can take a custom scalar for example like a date time or currency

value you know money and you could say well if you have this custom scalar on

the server if there's something of type money in this graph QL API then when you

get money use this decoder to get the money and then use this encoder to

encode the money and so it's just automatically going to apply a decoder

and if the decoder fails so so for example you could parse a date time

using an ISO 8601 decoder and your graph QL requests will fail if that

constraint isn't met because a custom scalar in graph QL represents some

guarantees about that data you know so like if a graph QL server is serializing

something in a date time format then it's it's giving you a promise that I

will serialize it in the ISO 8601 format which means I can make that assumption

when I decode the data so Elm GraphQL gives you this ability to just say for

this type of custom scalar decode it using this set of assumptions which

turns out to be a really nice way to work with with code to put those

constraints into a single module where you define this is how I deal with my

custom scalars so anyway I haven't been perfectly happy with the developer

experience because what you need to do is you need to like expose a certain set

of types or type aliases that you define in your custom codecs module and then

you need to define a custom encoder and decoder for each of those and I kind of

compile the code and it gives you these errors which are a little bit confusing

if you did it wrong but I'm thinking what if I had an Elm review rule and

package that as part of the Elm GraphQL command line interface yeah run Elm

review and I could have an improved developer experience where I can look at

it and I have the syntax tree for that custom codecs file and I can basically

get as fine grained as I want rather than relying on the Elm compiler to give

me sort of some general messages I can give some more precise messages and I

can give the messages in the language that makes sense for the Elm GraphQL CLI

yeah exactly you actually wouldn't necessarily need this CLI the Elm review

CLI because you could simply use the Elm review package you would have to do the

wiring yourself yes but though you could use it to do something like that yeah

definitely interesting interesting I love the idea of having it be rather

than you know like you said JS hint or these other tools in the JS ecosystem

that say here are the rules this is how you write JavaScript right right this is

having it be a platform that's extensible and gives you the tools to

look at the AST and do your own static analysis it's kind of interesting

because like so one of one of the best features of Elm format is that it's a

zero configuration formatter right yeah so you don't have these constant

arguments in different Elm code bases about should it be two spaces or four

spaces should it be a trailing comma or a leading comma actually don't know if

it's two or four spaces I don't care four exactly we don't care right and

that's a that's a feature yeah so how do you see this as different like why do

you think that it's the right choice to put the power and the configurability in

the user's hands in this instance even though this is such a strong feature

with Elm format to have zero configuration what's what makes that

different do you think I don't think it's right to compare it to Elm format I

would more compared to types in a way like in Elm you've got types you got

billions strings numbers etc but that's not where Elm's power comes from the

power of Elm comes from custom types so you types that you're tailored to your

own need so to your own business needs so if you want to build a user you build

your own user type which has this and that fields and it wouldn't make sense

to only use the built in types for you that's Elm provides you and I think

that's kind of the same thing with Elm review sure you have a set of rules that

tell you how your code should look like you remove unused variables do things

this way which is nicer do not import everything from module things like that

but a lot of times you really want to have something tailor made to your needs

right so for instance if you want to limits how your application works you've

got domains you've got let's say you have a whole section of your project

which deals with how you fetch data how you interact with GraphQL another one

that deals with business logic and you do not want to link those two you want

you don't want to have the one inputs the other then that is something very

custom to your needs to your application to how you built your projects same

thing with Elm conventions every team has coding conventions if they do not

they will soon I think yeah it makes sense to have customizable right so okay

so it seems like the way you're talking about on review it seems to me that you

look at it as fundamentally different than just a linter in a way because

you're talking about it like this is not just a way of enforcing standardized

code conventions yes it is not it is a way of enforcing constraints about your

code so it almost sounds like you're talking about it like an extension of

the Elm type system as a way to to catch certain constraints that you can't encode

with the Elm type system by itself exactly the way I see it is if Elm the

Elm compiler is your assistant Elm review is your second assistant and

incidentally Elm review can do linting but that's not all that it can do it can

be much more I think so if if I had a review rule for RegEx you know how you

know with the latest API for for RegEx and Elm you do RegEx dot from string and

then you have to pipe that through maybe dot with default RegEx dot never yes

that's how people usually do it yeah the older Elm API had this bug in it that

you could have a runtime exception if you passed in an invalid RegEx and so

okay that's nice it returns a maybe if there's something wrong with it but you

only notice later right so having a maybe there just feels like the kind of

thing that we should we want to know more at if we can't know it at compile

time can we know it at build time can we know it as a build step that analyzes

our code static analysis right and in a way the Elm compiler is just a type of

static analysis tool so in a way it's not really any different it's the same

stage it's like a compile time check it's just another tool to run alongside

the Elm compiler so could you do something that I mean it seems like you

could pretty easily just write a review rule that checks when you do RegEx dot

from string and then you look for instances of that in the AST in your

review rule and then you say okay if it's a string literal then take that

string call RegEx dot from string with that string yeah and then case just okay

good you succeeded nothing hey your RegEx is invalid and then you know that

you will never have a RegEx that doesn't work yeah exactly a drew plan on the

publishing of packages that does that nice so this is like a bigger topic than

just reviewing your code styles it's looking at I mean when you're able to

look at the literals in the code base then you can make certain guarantees

that you can't with the type system alone you could even have like a

positive integer yep type and you could say oh I can say positive integer dot

from literal and if I call that my Elm review rule will fail if I call it with

anything but a literal or if I call it with a literal that is negative yeah I

was going to say that you just stole it for me I was going to say it about the

RegEx you could have a create RegEx function that yeah it needs to be passed

a literal which is not something that you can enforce in Elm with a compiler

yes but yeah force it to be a literal and a literal that is a correct correct

RegEx I mean this out it sounds like a rabbit hole that's why I've been

spending nine months on this project this sounds like a rabbit hole that we

could do like a whole nother discussion on where yes I mean how do you use Elm

review to do dependent types wouldn't that be yeah wouldn't that be an

attention grabbing headline dependent types in Elm that sounds good to me

yeah awesome well thanks for sharing this this is super interesting and I'm

looking forward to discussing it more in the future yeah me too so if people want

to know more about it so just read the blog posts on my website and there's an

Elm review channel so elm dash review on the Elm Slack come talk to me come talk

to us in the in Slack and I really hope you enjoy it give me any feedback you

have even positive that's helpful for me and let us let us know what you build

with it because it's always helpful to see what people are actually building

with it and it's great for other people to see examples of what people are doing

to get inspiration definitely yeah that would be awesome yeah great well thanks

as always this is a lot of fun and talk to you next time yeah talk to you next