Does prettier offer a flag for trailing function commas? I'd be for it if so.

Yep, I'll enable

Do we need --print-width 110?

That is rough. I feel like I'll misread this every time.

Filed: prettier/prettier#872

Can we combine this with ESLint to force these to be wrapped in a block statement?

Looks like we have a bunch of these too. It's an interesting case since it follows the rules for normal normal expressions, but seems weird when you see it. @vjeux any thoughts on this one?

Ah, looks like maybe prettier/prettier#786?

If you remove the parenthesis, it displays the same way as you wrote it:

const buildPropertyMethodAssignmentWrapper = template`
  (function (FUNCTION_KEY) {
    function FUNCTION_ID() {
      return FUNCTION_KEY.apply(this, arguments);
    }
    FUNCTION_ID.toString = function () {
      return FUNCTION_KEY.toString();
    }
    return FUNCTION_ID;
  })(FUNCTION)
`;

https://prettier.github.io/prettier/#%7B%22content%22%3A%22const%20buildPropertyMethodAssignmentWrapper%20%3D%20template%5Cn%20%20%60%5Cn%20%20(function%20(FUNCTION_KEY)%20%7B%5Cn%20%20%20%20function%20FUNCTION_ID()%20%7B%5Cn%20%20%20%20%20%20return%20FUNCTION_KEY.apply(this%2C%20arguments)%3B%5Cn%20%20%20%20%7D%5Cn%20%20%20%20FUNCTION_ID.toString%20%3D%20function%20()%20%7B%5Cn%20%20%20%20%20%20return%20FUNCTION_KEY.toString()%3B%5Cn%20%20%20%20%7D%5Cn%20%20%20%20return%20FUNCTION_ID%3B%5Cn%20%20%7D)(FUNCTION)%5Cn%60%3B%22%2C%22options%22%3A%7B%22printWidth%22%3A80%2C%22tabWidth%22%3A2%2C%22singleQuote%22%3Afalse%2C%22trailingComma%22%3A%22%22%2C%22bracketSpacing%22%3Atrue%2C%22jsxBracketSameLine%22%3Afalse%2C%22parser%22%3A%22%22%2C%22doc%22%3Afalse%7D%7D

@vjeux Would there be any interest in handling this like the array in https://prettier.github.io/prettier/#%7B%22content%22%3A%22var%20foo%20%3D%20bar(%5B%5Cn%20%20%7B%5Cn%20%20%20%20foo%3A%204%5Cn%20%20%7D%5Cn%5D)%22%2C%22options%22%3A%7B%22printWidth%22%3A80%2C%22tabWidth%22%3A2%2C%22singleQuote%22%3Afalse%2C%22trailingComma%22%3A%22none%22%2C%22bracketSpacing%22%3Atrue%2C%22jsxBracketSameLine%22%3Afalse%2C%22parser%22%3A%22babylon%22%2C%22doc%22%3Afalse%7D%7D

The template literal approach is certainly an option if not.

Do you mind discussing it in prettier/prettier#786?

No problem.

Thanks!

Sorry I haven't pushed this yet. I'm going to revive that PR

Got lost when commas were changed to all. Feeling like we should include --print-width 110?

Yeah, I can run it again with wider to see the results, some of the lines get really crowded the further you move out from 80.

Oh because it stops wrapping other things we've manually wrapped?

@loganfsmyth the way prettier works is that it tries to fit as many things as possible within a single line. Usually, this is what you want for 80 columns. The main reason people extend it further is that sometimes you want to go beyond 80 columns, but prettier is going to do it all the time and makes things less readable in practice.

Yeah that is totally fair, I didn't fully think that through initially. I'm fine with trying out 80 for now, we can always increase it later.

One thing we'll have to consider is that we have a bunch of code snippets inside template literals that are currently formatted for 110 and those won't be reformatted, so those will stick out. If we reduce ESLint to 80 we'll have to go mark all of those. I guess we could just leave the max at 110 for now and rely on prettier for everything else?

You can use https://github.com/not-an-aardvark/eslint-plugin-prettier instead here

This is an interesting case. I guess it makes sense, but it makes the readability here worse to me at least, but I also don't think there's an obvious alternative.

You could define the type in a variable just above and have a reference here, so you don't need to have this weird inline.

I admit, the 80-char limit still feels too small to me :(

This is an interesting one where I feel like I'd probably have flattened the const binding names, rather than the function args, so the call itself was still all together. e.g.

const {
  filepath,
  value,
  options,
} = normalizePair(plugin, loadPlugin, config.dirname);

Here's a weird one...

We add parenthesis around all the assignment in order to call attention to the fact that this expression is mutating a variable.

Like that return above, interesting. Not sure why you'd want parens around this.