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

prettier integration POC #360

Merged
merged 12 commits into from
Feb 18, 2018
Merged

Conversation

Undistraction
Copy link
Collaborator

@Undistraction Undistraction commented Feb 11, 2018

This PR adds prettier and integrates it with eslint. It's for discussion so please take a look.

I have run it on all files in the src/ and test/ dirs.

Prettier's minimal options are here. I would recommend:

  1. Drop the 'Print Width' to 80.
  2. Lose the semi-colons.
  3. Use backticks instead of single quotes.

I have it configured (with VSCode) so it formats on save which I find to be very very useful. It really becomes part of your workflow - you don't need to think about formatting at all.

I've added it to the lint script. It could go into the lint:fix script instead, but I think it should happen transparently when linting.

It'll take some tweaking to get eslint happy with what prettier does, but I'll hold off doing that for the moment until we decide it's something we want.

closes #336

@char0n
Copy link
Owner

char0n commented Feb 11, 2018

Thank you for this POC.

Drop the 'Print Width' to 80.
I'd go for that. Let see what it will do to our jsdoc comments that are pretty long

Lose the semi-colons.
Don't trust ASI. I'd rather stay explicit with this one

Use backticks instead of single quotes.
We can switch later if there are reasonable amount of usecases.

Let's keep it on evolution level, not revolution ;]

Ok couple of things that I have questions about

  1. ) How does this play with our eslint config ? Parentheses around single parameter arrow functions / Add support for arrow-parens property prettier/prettier#812

2.) We will loose 2 lines after import statements; but I can live with that (prettier/prettier#1610)

3.) This is something that really sucks

4.) Spaces in functions declarations: prettier/prettier#3847; Is there some options for this ?

@Undistraction
Copy link
Collaborator Author

Don't trust ASI. I'd rather stay explicit with this one

This is part of what prettier does. With semis disabled it will still insert semis for cases where their absence would cause problems.

I'd go for that. Let see what it will do to our jsdoc comments that are pretty long

I'll take a look tomorrow

We can switch later if there are reasonable amount of usecases.

Np

How does this play with our eslint config

Prettier will win, so its a matter of changing eslint rules to be harmonious with how prettier formats and disabling all eslint autofixing. When we are happy with how prettier is formatting I can look at this.

We will loose 2 lines after import statements

Yep. This is not optional

This is something that really sucks

Not sure exactly what you mean - the wrapping?

Spaces in functions declarations

Looks like this is going to land shortly: prettier/prettier#3903

@Undistraction Undistraction changed the title prettier integration prettier integration POC Feb 11, 2018
@char0n
Copy link
Owner

char0n commented Feb 12, 2018

This is part of what prettier does. With semis disabled it will still insert semis for cases where their absence would cause problems.

Ok understand, let's keep the semicolons in for now.

Not sure exactly what you mean - the wrapping?

Wrapping of chained method calls. Seems really unreadable for me. Let's see how will it look at 80 chars.

@Undistraction
Copy link
Collaborator Author

Undistraction commented Feb 12, 2018

Got everything playing nicely locally so please take a look when you get the chance. Prettier now runs prior to eslint and tslint on npm run lint.

Looks like code climate has two issues for isArrayLike. Not sure why they are showing now, but can't argue. That is one ugly function ;)

If everything else is OK I'll create a separate PR for isArrayLike that reduces the use of return and get that in first, then we can merge this one.

@Undistraction
Copy link
Collaborator Author

If everything else is OK I'll create a separate PR for isArrayLike that reduces the use of return and get that in first, then we can merge this one.

@char0n Shall I get this done before this PR gets too out of sync with master?

@char0n
Copy link
Owner

char0n commented Feb 14, 2018

I'll look at this during tomorrow. Meanwhile I will not merge any code related or configuration PRs. Sorry for delay

Copy link
Owner

@char0n char0n left a comment

Choose a reason for hiding this comment

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

LGTM. Great job! Some constructrs look a little bit strange that is price for consistency I guess.

.eslintrc Outdated
],
"plugins": ["eslint-plugin-ramda"],
"plugins": ["eslint-plugin-ramda",
Copy link
Owner

Choose a reason for hiding this comment

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

properly format the array comprehension pls

@@ -57,8 +57,7 @@
},
Copy link
Owner

Choose a reason for hiding this comment

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

please drop the package-lock.json

eq(RA.isNotFloat(0), true);
eq(RA.isNotFloat(1), true);
eq(RA.isNotFloat(-100000), true);
eq(RA.isNotFloat(MAX_SAFE_INTEGER), true);
eq(RA.isNotFloat(MIN_SAFE_INTEGER), true);
eq(RA.isNotFloat(5e+0), true);
eq(RA.isNotFloat(5), true);
Copy link
Owner

Choose a reason for hiding this comment

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

the scientific notation has been dropped here, but was here by design, can we ignore here ?


eq(RA.isNotFloat(0.1), false);
eq(RA.isNotFloat(Math.PI), false);
eq(RA.isNotFloat(5.56789e+0), false);
eq(RA.isNotFloat(5.56789), false);
Copy link
Owner

Choose a reason for hiding this comment

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

the scientific notation has been dropped here, but was here by design, can we ignore here ?

@char0n
Copy link
Owner

char0n commented Feb 15, 2018

We can fix code climate issues after the merge. There are some conflicts to resolve in this PR. Can you check it out before we merge (by rebasing on top of currenct master) ? I'd like to rebase this instead of merging.

@char0n
Copy link
Owner

char0n commented Feb 16, 2018

Rerurning the ci build and if green, then merging.

I can see now that there are 4 pending comments that has not been addressed. Can you look at it pls ?

@Undistraction
Copy link
Collaborator Author

@char0n Those should now be addressed.

@char0n char0n merged commit a3109fc into char0n:master Feb 18, 2018
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.

Integrate prettier
2 participants