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

conditionals: add support for nested indentation #450

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

declanvong
Copy link
Contributor

We've had this in our fork for over a year now, and I noticed #432 pop up.

This PR adds support for nested indentation in conditional types and expressions, so that it formats as a tree.

@CLAassistant
Copy link

CLAassistant commented Nov 1, 2022

CLA assistant check
All committers have signed the CLA.

@declanvong
Copy link
Contributor Author

declanvong commented Nov 1, 2022

Ah, I think I accidentally made the commit on my personal account so the CLA assistant thinks I haven't signed it...

edit: yep, all fixed, just signed it on my personal account.

@dsherret
Copy link
Member

dsherret commented Nov 3, 2022

Cool. Thanks @declanvong! I'll try to take a look on the weekend. Very busy next few weeks because of work work.

@dsherret dsherret self-requested a review November 3, 2022 01:10
@bitnimble
Copy link

Bump on this one! I also have a couple more PRs - would you rather I just raise them all immediately? and then we can comment / discuss there? Most of them have linkable issues as well.

Otherwise I'm happy to raise them one by one if that makes it less stressful, lol

Copy link
Member

@dsherret dsherret left a comment

Choose a reason for hiding this comment

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

I just realized this PR makes it so that it will have nested indentation AND force a line per expression. There is already an option conditionalExpression.linePerExpression that handles that for conditional expressions and conditional types will maintain their formatting unless "preferSingleLine" is true. I added some failing tests. Would you be able to tackle updating the code to make them pass? If not I can work on it hopefully soon.

Sorry for my delay, as per usual!

@declanvong
Copy link
Contributor Author

declanvong commented Dec 6, 2022

Ah yep, I can take a look!

Note: I've literally just started back at work today and I might be busy with onboarding, so I might take some time as well :)

@declanvong
Copy link
Contributor Author

I checked out the new tests; I think that I will have to add something like conditionalType.linePerExpression in order to achieve the same thing that we have right now for conditional expr.

Does that sound okay?

@declanvong
Copy link
Contributor Author

Updates:

  • Added conditionalType.linePerExpression. Although name tbd, since it's not an expression... so maybe linePerBranch or linePerType might be might accurate? Not sure.
  • I lifted all of the conditional logic up into the head section instead of being in the body, so the same force_cons_alt_newline that's currently there will drive the forced newline.

@@ -2172,9 +2172,14 @@ fn gen_conditional_expr<'a>(node: &'a CondExpr, context: &mut Context<'a>) -> Pr
let colon_token = context.token_finder.get_first_operator_after(&node.cons, ":").unwrap();
let line_per_expression = context.config.conditional_expression_line_per_expression;
let has_newline_test_cons = node_helpers::get_use_new_lines_for_nodes(&node.test, &node.cons, context.program);
let has_newline_const_alt = node_helpers::get_use_new_lines_for_nodes(&node.cons, &node.alt, context.program);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is just a typo fix, const -> cons

? C extends D
? c
: testingTesting
: testingTestingTestingTesting;
Copy link
Member

Choose a reason for hiding this comment

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

@declanvong sorry for my delay here. I just added this file and test, but it fails. I think this is the expected output?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, looks like that maybe one of the indent conditions is listening to linePerExpression instead of useNestedIndentation? I'll take a look

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed, but important to note that this change is not backwards compatible, it changes existing formatting, so it'd be a version bump.
There's a test with some existing formatting that I've updated (ConditionalType_All.txt::should format an individual condition that goes over the limit).

Since both linePerExpression and useNestedIndentation are not enabled in that test, it goes from being formatted originally like this:

type Type<T> = T extends string ? number
    : T extends hereIsAVeryLongExtendsClause
        ? testingThis
    : boolean;

to this (flattened indentation):

type Type<T> = T extends string ? number
    : T extends hereIsAVeryLongExtendsClause
    ? testingThis
    : boolean;

Enabling useNestedIndentation without linePerExpression gives:

type Type<T> = T extends string ? number
    : T extends hereIsAVeryLongExtendsClause
        ? testingThis
        : boolean;

which also seems correct.

So there's no way to get the original formatting in this new world, but maybe that's good? if the original formatting was always not technically correct or wanted. after all, that trailing : boolean really is part of the inner conditional, not the outer one, so I feel like the new formatting is better anyway as it makes that more obvious.

@b0o
Copy link

b0o commented Nov 1, 2023

Hopefully this PR can be resurrected, the lack of this feature is one of my only gripes with dprint!

@chekrd
Copy link

chekrd commented Dec 13, 2023

@declanvong @dsherret
Hi guys. Researching the code formatter for our company as ESLint announced their stylistic rule deprecation. DPrint not supporting conditional types syntax is a blocker for us (we consider Prettier and Biome, but DPrint seems to be the best). What is the status of this PR?

@todor-a
Copy link
Contributor

todor-a commented May 15, 2024

Hey, @dsherret can we do something to help move this along? We would love to see it merged.

@g-plane
Copy link

g-plane commented May 22, 2024

Due to the inactivity of this repository, what about fork this dprint plugin and maintain by ourselves?

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.

None yet

8 participants