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

Add types to options.js #126

Closed
wants to merge 13 commits into from

Conversation

henriquecbuss
Copy link

This PR is a step towards #125, and adds types to options.js.

It also fixes a @ts-expect-error in the same file -- that's why some other files are touched.

Thanks for the project, glad I can help in some way 🙏

Copy link
Owner

@jfmengels jfmengels left a comment

Choose a reason for hiding this comment

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

Thanks a lot for helping with this 🙏

lib/error-message.js Outdated Show resolved Hide resolved
lib/options.js Outdated Show resolved Hide resolved
lib/options.js Outdated Show resolved Hide resolved
@henriquecbuss
Copy link
Author

@jfmengels all of the comments should be addressed 🙂

Comment on lines +48 to +49
if (flag.alias) {
object[flag.name] = flag.alias;
Copy link
Owner

@jfmengels jfmengels May 7, 2023

Choose a reason for hiding this comment

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

There has to be a way to tell TS that flag.alias is always false, right? 🤔
(Not that I necessarily want to remove it, I'm mostly intellectually curious 😅 )

Copy link
Author

Choose a reason for hiding this comment

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

Copy link
Owner

Choose a reason for hiding this comment

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

Yes, that's what I meant. I don't know how smart ts-reset makes filter in this case, but I'd imagine that in this case TS will not remember that flag.alias is non-falsy. If it does, then yes, otherwise, it's so close 😁

Copy link
Contributor

@lishaduck lishaduck Jun 15, 2024

Choose a reason for hiding this comment

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

Fixed it locally, I tossed it into a gist:
https://gist.github.com/lishaduck/8cabda9ae913535f702a4376712d4608

I'd just give a patch, but I'm tweaking some other types. I'll PR soon (unless I forget 😉) EDIT: #155
I'm planning on rebasing that on this.

It's a patch now!

Copy link
Owner

@jfmengels jfmengels left a comment

Choose a reason for hiding this comment

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

This LGTM 👍 , but the npm run tsc test is failing, because these changes have introduced problems for the regular tsconfig.json configuration.

lib/options.js Outdated Show resolved Hide resolved
@henriquecbuss
Copy link
Author

henriquecbuss commented May 8, 2023

There are still a few errors in the regular tsconfig.json configuration, related to options.elmJsonPath being nullable. I'm not exactly sure how to go about this... does it make sense for it to be nullable? Is it even possible to run elm-review without an elm.json? Maybe we should error out if we can't find it?

@jfmengels
Copy link
Owner

I can make sense for it be null, when you're running commands like elm-review --help or init for instance.
But for the review part, it should never be null. When it is, we will be throwing an error somewhere. I'm not sure what's the best way to prove that to TS. I guess casting could be an okay thing for now, until we figure out something better (if you don't want to scratch your head too much). Other ideas welcome, I'm not super familiar with TS.

Comment on lines +63 to +66
export type OptionsForRunningElmReview = Omit<Options, 'elmJsonPath'> & {
elmJsonPath: Path;
};

Copy link
Author

Choose a reason for hiding this comment

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

If we think more types are going to have to change for running elm-review, we could also abstract this a little:

type OverriddenFieldsForRunningElmReview = { elmJsonPath: Path, ... }

export type OptionsForRunningElmReview = Omit<Options, keyof OverriddenFieldsForRunningElmReview> & OverriddenFieldsForRunningElmReview

Also, this name is pretty long, but I couldn't think of anything better 😅

Comment on lines +52 to +57
if (!elmModulePath || !options.elmJsonPath) {
AppState.exitRequested(1);
return;
}

const optionsWithElmJsonPath = {...options, elmJsonPath: options.elmJsonPath};
Copy link
Author

Choose a reason for hiding this comment

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

For now, we just exit if elmJsonPath is null. We could have better errors if you want (if so, we could wrap this in a function and just call it where needed) 🙂

Copy link
Owner

@jfmengels jfmengels left a comment

Choose a reason for hiding this comment

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

Sorry for long delay! I was on a much needed vacation break!

I think the PR looks pretty good in general. Looking at the tests (npx jest to run those locally), some behavior has changed.

  1. The check for elm.json is done earlier than the check for bad flags (unknownCheck), and now that triggers different and less helpful errors than before.

  2. Somehow the suppressions behave differently compared to before?

Sorry again for the delay, and I hope it's not too much of a bother (resuming) working on this. If it is, simply let me know and I'll try to get this across the finish line. I appreciate all of your help @henriquecbuss ❤️ 😊

lib/options.js Outdated Show resolved Hide resolved
@henriquecbuss
Copy link
Author

No worries! A much deserved break, for sure.

I'd love to keep working on this, but a lot of stuff (work + school) is going on at once, so I will not have time to continue working on this for a while (probably at least a month). It's fine if you want to finish this PR yourself, as that is quite a long time, but it's also fine if you want to wait for me to finish it (just know it will take a while).

Hopefully I can contribute more as soon as I get more free time 🙂

@lishaduck
Copy link
Contributor

lishaduck commented Jun 23, 2024

Oh, @jfmengels, this can be closed. You made the types changes already, the only changes left break the snapshots, as you observed. I plan on investigating it, but as the main purpose is complete I think it can be closed.

@jfmengels
Copy link
Owner

Alright, thank you for looking into this @lishaduck. And thank you for the original work @henriquecbuss 🙏

@jfmengels jfmengels closed this Jun 23, 2024
This was referenced Jun 24, 2024
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.

3 participants