[WIP] Prettier plugin for eslint

[dsych]

Adding code auto formatting with Prettier through grunt-eslint. See discussion. In this version eslint-config-prettier and eslint-plugin-prettier for eslint are utilized in conjunction with grunt-eslint to auto-format code in watched directories.
While I got everything it working, there is a problem with grunt-eslint dependencies. It depends on the 3.0.0 version of Eslint (see), however, eslint-plugin-prettier uses a minimum of 3.14.0 of Eslint. If not satisfied, the following problem arises. So I had to manually, update dependencies for grunt-eslint, which is not the best way in my opinion. Apart form that, everything is operational.
Moreover, I have another version of achieving the same result of prettier formatting bypassing additional plugins. It does the direct calls to prettier through grunt-exec. Although I only got it formatting the whole src folder, it also works. I have a couple of ideas of how to restrict formatting, but they are not working properly. Let me know if you are interested in that approach more.

cc @humphd

[dsych]

As stated before, outdated dependency is the reason why the build fails.

[humphd]

Filed adobe#13290 upstream to see if we can land this there vs. here. If they don't want it, we can move forward with doing it just in our fork.

[dsych]

@humphd I was thinking about submitting PR to grunt-eslint with the request to update their dependencies.

[humphd]

@dsych go for it.

[dsych]

@humphd I fixed the problem with incompatible dependencies, just needed to update to the latest version of grunt-eslint which uses the latest version of eslint. Now it is pretty much ready,

[humphd]

This is very cool.

One thing I noticed running it is that we are including the following submodule in our src list:

modified:   src/extensions/default/brackets-paste-and-indent (modified content)

We shouldn't be touching that file.

I also tried running this on the code, and put up a compare branch to show the difference, see mozilla:master...humphd:prettier-plugin. From looking at this, we should fix the following:

• Use 4-space indents vs. 2-space
• Fix the way /** ... */ comments get done, they look odd

We should add some kind of precommit hook, see https://github.com/prettier/prettier#pre-commit-hook-for-changed-files

I'll also share this compare branch with Adobe and see what they think. It would be ideal to do this upstream vs. here, if possible.

[humphd]

This file should be 4-space indented.

[humphd]

Prettier 1.0 release today http://jlongster.com/prettier-1.0. We should watch for updates on the plugin dep.

[dsych]

@humphd

1. Grunt-githook is now part of the build. Before every commit grunt-eslint --fix is ran and every file that falls out of line is later added to the current commit.

2. Regarding malformatted comments, I believe this is supposed to explain it.

3. Before building, I suggest running "grunt eslint:src-fix" because now we don't have --fix option in default eslint task.

Finally, I am aware that there are a bunch of "test" commits in there, will rebase later.

[humphd]

This seems wrong to me. We'd want this to run automatically, not just when you manually run build. That is, when I commit, or maybe even when I just stage changes, it should run. There should be no manual intervention required, or people will forget/not-know to do it.

[dsych]

@humphd This is required to create githook scripts. The formatting does run automatically on before every commit. My comment above

Before building, I suggest running "grunt eslint:src-fix" because now we don't have --fix option in default eslint task.

Only refers to the first run of the build. Eslint does not have auto-fixing set, so styling will fail the build and you will never create githook scripts. So instead you need to format code manually once, and then it will run properly on every commit. After formatted code is committed to the master, there will be no need for manual intervention.

[dsych]

@humphd At this point, it does not seem that Adobe is really interested in formatting with prettier, so should we just keep on working on it here or give them more time to think?
Moreover, I would appreciate if you could test my latest patch and give a review, at your convenience. I feel like putting auto formatting on every commit is a little of an overshot, as it is an extra operation that takes time, which is just annoying. Instead I suggest that we do formatting before code is being pushed.

[humphd]

We should probably just do it here. Can you fix the merge conflict you have?

[dsych]

@humphd fixed the merge conflict, however now Travic is failing the build because of the prettier rules in the eslint task. I really don't to commit all of the formatted files now, because it will make the PR messy.

[humphd]

OK, great. I'm not going to try and land this while the other students are still scrambling to get PRs done this week. I'll circle back on this later. Good work.

[humphd]

Question about the git-hooks: will what you did work on Windows?

[dsych]

Tested with GitBash for Windows and CMD for Windows 10 before the Anniversary update. Everything runs smoothly.

[dsych]

@humphd Are you still interested in this PR or should I close it?

[humphd]

No, I'm still interested. We just froze the tree for a launch next week, but we'll come back to this. Software takes time, don't give up!

[dsych]

@humphd Congrats on a new release, can we continue now?

[humphd]

Two things I want to figure out here:

• we need to get comments to format correctly
• we need to figure out a transition plan for PRs or other patches we need to land that don't use this new styleing--probably a grunt/npm task you can call to manually do this.

[Pomax]

@humph what is the issue with comments? Is this a thing that we need to fix "in prettier" or is this a style thing we'd have to correct for in all our files?

[dsych]

@humphd what is weird about comments, in your opinion? Here is a link to the sample from the formatted branch you did earlier.

I believe we can overwrite comment formatting from prettier in favor of eslint. Check out guidance and decide if this is an acceptable way of formatting. I believe that eslint formats comment by default based on this issue

For the PRs that do not require formatting, are we talking about specific paths that should be excluded or a user prompt to decide if we want to format?