All the changes you mentioned sound good (even switching single quote), now the big question is: do we think that the current suboptimal behavior is worth a breaking change. I’m not sure (in either way).

For consistent key quotes, I think we should just do it regardless, I’m not sure why we haven’t already.

vjeux on 16 Dec 2017

I'm not certain either. The CLI breaking changes listed are quite small, and probably wont affect a large percentage of projects. The changes to the options are are trivial because you can just change them in a config file, so the "migration path" (if you can even call it that) is quite simple.

But there's always the risk with breaking changes that people will not know that and simply stick with the older version.

azz on 16 Dec 2017

drop Node v4 (Maintenance LTS End: April 2018)
remove all deprecated options
remove exitCode: 2 from CLI, or figure out when should we apply exitCode: 2 as it's very unclear now.

ikatyang on 16 Dec 2017

👍11 ❤2 👀1

One thing I'd personally find really nice: removing the dependencies on non-JavaScript parsers. (In particular, all parsers other than babylon.)

For example, a lot of people aren't using prettier to format TypeScript. But if they install prettier, it pulls in that whole package, which is something like 30 megs by itself.

That makes me sad. If prettier adds support for python and installing prettier starts downloading python binaries, that would make me really sad.

I would be delighted if prettier could stop trying to ship all of the parsers for anything anyone might want to format. Presumably then trying to format (say) a .ts file would give you "Error: to use prettier to format typescript, you'll need to add the 'prettier-ts' package; run `npm i --save-dev prettier-ts`".

bakkot on 16 Dec 2017

👍1

@bakkot Current package is 1.54 MB with zero dependencies on npm.

npm-module-stats

$ npm-module-stats --name=prettier --version=1.9.2 --format=minimal 
 Requesting module [email protected]
Results:
Total Size  1.54 MB
Total Dependencies  0

$ npm-module-stats --name=prettier --version=1.5.3 --format=minimal 
 Requesting module [email protected]
Results:
Total Size  1.11 MB
Total Dependencies  0

$ npm-module-stats --name=prettier --version=1.4.x --format=minimal 
 Requesting module [email protected]
Results:
Total Size  1.03 MB
Total Dependencies  0

$ npm-module-stats --name=prettier --version=1.3.x --format=minimal 
 Requesting module [email protected]
Results:
Total Size  943 kB
Total Dependencies  33

azz on 16 Dec 2017

👍1

@azz Ah, I missed that the package.json in the repo isn't the one which gets published, sorry.

(npm-module-stats apparently gives compressed compressed size, not on-disk; on my machine a fresh install ends up at 6.3 megs, most of which is the various non-JS parsers. Still, probably not worth worrying about.)

bakkot on 16 Dec 2017

It's the size of the tarball that's on npm:

$ du -h $(npm pack prettier@latest)
1.5M    prettier-1.9.2.tgz

azz on 16 Dec 2017

I’d like to make a poll to see if the bracket-spacing option could be removed: https://github.com/prettier/prettier/issues/715#issuecomment-281096495. It’s harder to say no to new spacing options when this one exists.

lydell on 16 Dec 2017

👍5 👎4

Facebook uses no-bracket-spacing, and it's actually kind of growing on me.

azz on 16 Dec 2017

👍9 👎2

Would it make sense to extract the parser and printer files to separate packages? i.e. you’d do npm install --save-dev prettier @prettier/plugin-js @prettier/plugin-markdown prettier-plugin-python,. This would mean that Prettier doesn’t have to include all languages it supports by default, and that folks could release new parsers before they’re completely ready for production. Plus, this would let the Prettier core stay small and testable.

j-f1 on 16 Dec 2017

It's possible but would require some thought about what would be in the plugin API. doc-builders, utils, etc. Multiparser would require an API and it would (potentially) limit the integrations you could do between different plugins.

azz on 17 Dec 2017

Regarding extracting the printer, see #2029.

lydell on 17 Dec 2017

Multiparser would require an API and it would (potentially) limit the integrations you could do between different plugins.

How about this?

const { parseEmbedded } = require('prettier')

module.exports = function parser(code, ...) {
  return concat([
    // ...
    parseEmbedded(code, languageHint)
    // ...
  ])
}

(where languageHint is the fenced code block title, or the type attribute of the <script> or <style> etc.)

j-f1 on 17 Dec 2017

For me seamless installing of prettier is the greatest feature. I don't care big package size since it's zero dependencies and usually not used as subdependency. Splitting package will require more configuration/installing and it's IMO worse DX.

TrySound on 17 Dec 2017

👍1

_If_ we split things up, it will be a huge task. I'd say we don't do anything such for 2.0. Better to focus on the easier stuff. (I also agree with @TrySound that it is super nice that Prettier is so easy to install.)

lydell on 17 Dec 2017

👍4

I've actually thought about splitting some parts of the project in separate packages (like a monorepo) to force us to have clear boundaries between the different parts of the code (even using @azz's ESLint rules for monorepos), like CLI, formatting, config, etc.. we do have a separation of files today, but it's not clear what are the dependencies of each part. And we'd still ship a single package, so no changes at all for users.

After that it would be more easy to create different bundles (e.g. for web) as we'd know exactly how to use only specific parts (i.e. only include formatting parts, not the CLI, config, etc.)

duailibe on 17 Dec 2017

👍2

Plus that would make it easier to create custom parsers/printers, since the API is already used internally.

j-f1 on 17 Dec 2017

Regardless, we should probably create a separate issue for this since it would be only an internal change and so unrelated to 2.0

duailibe on 17 Dec 2017

👍2

@duailibe

Regardless, we should probably create a separate issue for this

👍 ✅ #3511 🔼

j-f1 on 17 Dec 2017

👍1

Facebook uses no-bracket-spacing, and it's actually kind of growing on me.

If we were to remove the option, I'd vote to make "no spacing" the default, to be consistent with other brackets

duailibe on 17 Dec 2017

👍4

@duailibe I like the style with spacing since it’s easier to focus on the stuff inside the brackets if there’s whitespace around it IMHO.

j-f1 on 17 Dec 2017

👍20

We probably can't change the value and remove the option at the same time - we don't want people to not upgrade because it changes too much of their code.

azz on 17 Dec 2017

👍6

@j-f1 That's pretty much what people who asks for spacing between [] and () say

duailibe on 18 Dec 2017

Let's kill it.. 🔥

lipis on 18 Dec 2017

Let's take the bracket spacing discussion in a different issue as well: https://github.com/prettier/prettier/issues/3520

lipis on 18 Dec 2017

👍1

A major semver break is a rare and valuable opportunity to refine defaults. (I think everyone, maintainers and users alike, would really love if nobody used options).

--trailingComma=es5 is the only default I'm aware of that is regularly overridden, but I don't think it's responsible to go off anecdata and hearsay for questions of popularity.

It might be worth considering, in advance of P2.0,

Scraping github for .prettierrc files.
a. Maybe also trying to parse out commands including prettier in a package.json scripts entry.
Adding optional telemetry to prettier (for option usage only).
Developing & promoting a user survey (eg; echo the link 10% of the time the CLI is run, link on readme, etc).

I'm leaning towards 1 and 3 (3 could be useful more broadly than options, if we have other open questions).

rattrayalex on 18 Dec 2017

👍3

For "consistently quoting object keys"; this would be a huge problem for Airbnb in particular. Whatever the default is, a configuration option to "only ever quote when needed" would be very important. Is that something prettier would be willing to have in this v2?

ljharb on 18 Dec 2017

👍5

@rattrayalex, while I agree it would be good to try to get some more metrics here, and those are probably worth pursuing, unfortunately it's going to be hard to split out "did not configure because prettier does the thing I want" from "did not configure because 'no configuration' is more valuable than the thing I want".

@ljharb, fwiw I also like prettier's current style here, but it would be good to hear why Airbnb considers it so important that it remain as is. (For my part, the only reason I prefer the current style is that I like changes to be local - removing 'a-property' from an object literal shouldn't generally change the formatting on other properties in the literal.)

bakkot on 18 Dec 2017

👍2

Hmm. I think I'd rather keep the current behaviour than change it and add an option.

azz on 18 Dec 2017

👍2

@bakkot oh, to clarify: I think that the only property keys that should ever be quoted are non-identifiers; in other words, adding and removing a key never changes the quoting of any other key. Airbnb doesn't use any of eslint's "consistent" options; only the "as-needed" option.

ljharb on 18 Dec 2017

@bakkot good point – with opt-out telemetry, we'd still get that data, right?

rattrayalex on 19 Dec 2017

Very glad to have @ljharb here re; blockers for airbnb.

@ljharb Do you have any wish-list items that might be appropriate for a 2.0 release?

Is there a separate issue where we can discuss quoted object keys? (I also prefer the current behavior, but would rather discuss elsewhere)

rattrayalex on 19 Dec 2017

👍1

@rattrayalex #3108 and #3107 are the ones we've filed; the other one is likely to be relatively contentious: basically, there's a number of places that multiline should be forced (the way prettier currently works), but in the cases prettier currently forces single-line, we want both options to be permitted, so the developer's explicit choice of single- or multi- line can be preserved. In other words, we want prettier to never collapse anything, only expand when needed.

ljharb on 19 Dec 2017

👍2

Interesting; I could imagine you having some fun with #3107 if you have the time to fiddle.

Do you have an issue filed for "only expand when needed"? I think you're correct that prettier would ~never adopt that wholesale, but that is the current policy with objects at least. Perhaps there are only a handful of cases you're really interested in which might be worth discussing (though not on this thread).

rattrayalex on 19 Dec 2017

Every case: objects, arrays, jsx elements - anything that is explicitly chosen by the developer to be multiline, needs to remain multiline.

ljharb on 19 Dec 2017

❤1

Interesting... opened https://github.com/prettier/prettier/issues/3524 for discussion.

rattrayalex on 19 Dec 2017

❤1

Since we're throwing out ideas, one thing I found when attempting to work on prettier in the early days was that it was hard to work out all of the node types without any sort of type hinting (TypeScript or Flow). I know it's been discussed before (although I can't find the issue), but at least some of us find writing typed code much easier on a larger unfamiliar codebase.

Given that prettier itself is based on a Haskell pretty printer, I'm curious how receptive people would be to convert the project say to TypeScript. Obviously this would only be for development, the package would be JavaScript code runnable by whatever version of node we wish to support (although I'm with @ikatyang for dropping node v4 support). I'd be happy to help if it's just manpower stopping us from doing so.

aboyton on 19 Dec 2017

It's a no vote from me for Prettier.ts. I find TypeScript causes more pain than pleasure with codebases that are mostly pure (in the sense that we don't do OOP, don't often mutate, etc), and the tooling overhead hinders productivity.

What we _could_ potentially do is use the TypeScript JSDoc with tsc --checkJs, and that way we could write .d.ts files for AST nodes without having a compile step. Flow comment types are another alternative.

The issue is however that the type-checking quality is only as good as the quality of the AST definitions, which will be very difficult to keep up-to-date.

Given that prettier itself is based on a Haskell pretty printer, I'm curious how receptive people would be to convert the project say to TypeScript

I'm not sure I see the link between Haskell and TS?

azz on 19 Dec 2017

👍4

For the telemetry: what if you hashed the SHA of the initial commit in the caller’s git repository for use as a UUID? This would be a way to track individual projects without providing too much info or being susceptible to over-reporting when running on CI.

j-f1 on 19 Dec 2017

@azz I'd also add #1080 to the list

duailibe on 19 Dec 2017

👍4

Great list. Thanks for putting it together. Here's my argument in support of https://github.com/prettier/prettier/issues/1139#issuecomment-316096507

austinkelleher on 19 Dec 2017

@rattrayalex:

I don't think it's responsible to go off anecdata and hearsay for questions of popularity.

It might be worth considering, in advance of P2.0,

Scraping github for .prettierrc files.
a. Maybe also trying to parse out commands including prettier in a package.json scripts entry.

Adding optional telemetry to prettier (for option usage only).

Developing & promoting a user survey (eg; echo the link 10% of the time the CLI is run, link on readme, etc).

We could also use the GitHub dataset in Google BigQuery to find configuration files (and even search their contents!). I personally lean against adding telemetry, due to both complexity and potential pushback from users. The user survey sounds like a relatively easy way to gather feedback, but it also requires active participation and would likely bias against any "silent majority".

EDIT: It may also be worth looking at ESLint config files, given the popularity of eslint-plugin-prettier.

josephfrazier on 19 Dec 2017

👍2

We can use the Twitter account to conduct these polls :) https://twitter.com/prettiercode

If we go with user surveys let me know what we want to ask them and I'll tweet them..

lipis on 19 Dec 2017

I'm a bit late here but here are my opinions:

I strongly agree about moving towards separating out packages that don't relate to JS. Markdown is an iffy one, as it it sort of nice to automatically format markdown in the middle of a JS codebase, when they have JS inside of them. But adding Python seems crazy to me. That should be a completely separate project, owned by that community, with its own space to grow into a style that the Python community prefers. Mixing them all together here seems like a world of pain not only maintenance-wise, with more issues and overlapping communities. I wouldn't add any more to prettier than it already does (and if needed, move out the low-level printer so other can use it).

1139 - Put a space after the n in function () {}

I still disagree with this. This is a very simple point with lots of questions underneath it. Do you mean only anonymous functions? Or are you also saying named functions, like function foo () {}? That is a huge change for prettier and one that I disagree with. And since only doing it for anonymous functions causes inconsistencies with named functions, generator functions, etc, let's just keep it consistent. I know there are people who prefer the other way, but in my opinion we should keep drawing the line here. In a year we will have many more config options if we go down the route of adding more config. We've listened to the community on many things, but we don't have to cater to every need.

838 - Consistently add quotes to object keys.

To clarify: you are saying if there is a key that requires quotes, all of the keys are quoted? Otherwise they are left unquoted. I'd be open to that but it does seem a bit too opinionated. Sometimes just one key is quoted in a big object and seems like a big price to pay, and is there much benefit?
Changing the default value to single quote would be great, we always meant to do that

jlongster on 19 Dec 2017

👍18

@rattrayalex #3108 and #3107 are the ones we've filed; the other one is likely to be relatively contentious: basically, there's a number of places that multiline should be forced (the way prettier currently works), but in the cases prettier currently forces single-line, we want both options to be permitted, so the developer's explicit choice of single- or multi- line can be preserved. In other words, we want prettier to never collapse anything, only expand when needed.

I understand the desire for this, and it would be a radical departure for prettier. It's a different philosophy for printing, and one that I disagree with. You lose a lot of determinism if you do that. The win for prettier is that you can take a file X and, no matter what is in there now, you will get Y back. There are a few places we look at the contents of X, such as preserving blank lines, but otherwise we ignore it. The more we look at X to determine the output of Y, the more we've lost on consistent code across files.

I'm certainly biased; it gives me great pleasure if I have a function whose args have been broken up:

function compile(
  parser,
  shouldExtendScopes,
  lazilyCompile,
  otherOption
) {
  // ...
}

And I remove otherOption and it collapses it back:

function compile(parser, shouldExtendScopes, lazilyCompile) {
  // ...
}

Removing that functionality would be a big loss IMHO.

jlongster on 19 Dec 2017

👍16

@jlongster Have you seen my argument for https://github.com/prettier/prettier/issues/1139#issuecomment-316096507

I'm curious about your thoughts on that.

austinkelleher on 19 Dec 2017

@jlongster the most common and consistent standard for function keyword spacing in the ecosystem is "function keyword", "space", "optional name", "argument list".

You lose a lot of determinism if you do that.

The use case we have includes using prettier and eslint - and with that, we get way way more determinism than prettier can possibly provide. By loosening prettier in this way, opt-in of course (because I agree that if you want this behavior you should be able to have it), what's being enabled is more determinism, overall, because it helps allow us to use both tools to maximize that.

ljharb on 19 Dec 2017

👍1

@austinkelleher Honestly it's not something I, nor many people I've worked with, have run into. Many different styles of syntax "happen" to help with an arbitrary regex or some other pattern, but it's not really a big enough issue to crack open something as big as a style change here for function definitions.

@ljharb I don't see what the issue is using prettier and eslint. Use eslint-prettier-config (or whatever it's called) to disable the formatting-specific rules in eslint and you use both for what they are good at.

You do lose determinism. The use case I show above would show up all over the place - prettier broke the function across lines but then somebody removes arguments and it's left expanded across lines. Now in code reviews you'll have "the function definition fits on one line - please collapse it". These these show up all over the place. I don't see how eslint helps with determinism - use it for what its good at, which is analyzing semantics, and don't use it for formatting. That's prettier's official stance. Prettier should always output Y no matter what is in X, that's what the determinism means. You objectively lose that the more and more you depend on what's in X.

Adding another option, especially something that huge, is not an option IMHO. When somebody uses prettier they expect a certain output. That would be such a huge change that you don't really know what style a project has even though it uses prettier. Right now you can generally know what style you're going to get, even though options tweak very small things like quotes. And even though we've added some options, I hope we're still embracing relatively zero config.

There's always an option to fork. I still that's the way to go if you want a space after function, or some other large change like changing when it collapses things. That's the beauty of open source. It should be relatively easy to maintain and rebase changes on newer updates of prettier; those kinds of things are usually relatively small code tweaks. In my current app I've forked several popular open-source projects to tweak things for how I want them to work. I think that's a more ideal situation than trying to cater to the enormous size of the entire JS community.

jlongster on 19 Dec 2017

👍6 👎1

@jlongster the issue is that when "the choice of multiline" is an explicit developer intention, and prettier removes that, eslint can no longer have any idea that that choice was made in the first place. Disabling the formatting-specific rules in eslint doesn't work unless prettier exactly matches our configuration for those rules - which it decidedly does not. If/when we're able to get prettier working at airbnb (and with our public config), it will be with disabling zero eslint rules only.

Certainly this would require losing some determinism in prettier when the option I'm asking for is enabled. If adding an option like this is a nonstarter, then that's something we'll have to consider. However, the goal would not be that "prettier implies X style", it would be that "prettier-eslint implies X style".

Regarding a space after function; eslint already handles that for us, so there's no need to fork - the only place where that becomes a possibly necessity is when prettier is destroying information that eslint can not restore: namely, collapsing things (destroying the developer's intention to make it multiline) and removing parens (destroying the developer's intention to add the unnecessary parens for whatever reason).

I think that the ease of forking is a wonderful thing about open source; but that doesn't mean forking has no cost. Forking a project and constantly rebasing on top of the upstream is a very expensive thing to do, and in general isn't good for the overall ecosystem (when shared broadly - when it's done inside a single app for your own use, sure, go for it).

ljharb on 19 Dec 2017

👎4

You are right about forking having a cost, but the size of the JS community is so huge that my philosophy is that it's better for a few smaller tools to exist than one single giant one. Especially in this case, where it's just formatting, there are no runtime dependencies, and it's easy to swap out. (I still believe it's not really that hard to maintain prettier forks, the chance of conflicts is low due to tweaks only involving few lines). If Airbnb wants to use a prettier version that respect developer multiline breaks, why not fork and make that? As you said, within your own domain forking makes sense.

What you want is simply something that prettier from the start was built to avoid. It was built to explicitly ignore any developer intention, especially "the choice of multiline". If you want that, prettier probably isn't going to work very well, and you're probably better using eslint for formatting and using eslint --fix. Why can't you use that fix command if you're wanting to use eslint for everything?

There's a point where a tool gets so general that it loses its own definition and becomes too abstract. Adding options to fundamentally change the printing algorithm crosses that line for me.

(Note that I say this full respect and knowledge of the complexities of internal dynamics and maintaining existing codebases and tools and variety of cultures within companies. It's a valid request. I just know that prettier is going to be receiving these kinds of requests until the end of time, and will implode on itself if try to cater to all of them. I don't believe the full weight of all existing JS styles should be on prettier)

jlongster on 19 Dec 2017

👍17

I think it's written in the instructions, that if you want to combine prettier with eslint you have to disable all the formatting rules.. if you don't, then you are on your own I guess..

lipis on 19 Dec 2017

@lipis we've made some changes to eslint itself in the last month that makes that not true. Currently you don't have to disable any of the formatting rules if they're configured correctly, and you use prettier-eslint.

ljharb on 19 Dec 2017

👍3

@ljharb Regarding "the choice of multiline" being an explicit developer intention: I see what you mean. My _question_ is: What about when the user _did not_ intend to use multiline? For example:

const formatted = stripNumberString(
  (number / suffixValue).toPrecision(precision),
);

Now, somebody needs that inner expression somewhere else, so they move it into a variable:

const standardFormatted = (number / suffixValue).toPrecision(precision);
const formatted = stripNumberString(
  standardFormatted,
);

Would the above pass your code review? Or would you ask the developer to join that function call to a single line?

const standardFormatted = (number / suffixValue).toPrecision(precision);
const formatted = stripNumberString(standardFormatted);

Remember, one of Prettier's goals is to get rid of code formatting discussions. What's your take on this?

Also related: elm-format behaves like @ljharb is describing: If an expression is single-line in the input, it will stay single-line in the output. Same thing for multiline. This is a double-edged sword. Sometimes it's nice to force some things to be multiline. But sometimes when I hit "format" in my editor I look at some refactored code and get confused why a bunch of short lines don't jump together into a single one, like I'm used to in Prettier. And sometimes I write a really long line and am surprised when it isn't automatically broken up. See https://github.com/avh4/elm-format/issues/324

lydell on 19 Dec 2017

👍1

Yeah, elm-format uses a completely different formatting philosophy. It doesn't automatically break expressions across lines based on line-length. It forces the user to make that decision.

Combining both is weird; if you want to respect the user's intention, you probably want to fully embrace that and never do automatic breaking line prettier does. It's just a different algorithm that should exist as a different printer.

It's not a bad way to do it, but I found that prettier works better for JS. Elm was able to take advantage of being early in the language and could make rules based around it. It doesn't need the line width breaking as much. gofmt doesn't do it either; in go the syntax simply makes it more difficult to write long lines and it just simply splits things out vertically.

Due to the variety of existing JS idioms I think it's a better fit for JS to collapse things when possible according to line width (think of nested function with an object at the end like foo(bar(baz({\n .... \n })))). It fit the existing styles really well; it'll collapse those calls and expand the inner object across lines like you'd expect.

Note that we due respect objects original expansion which covers most cases.

(EDIT: It would also be quite a burden to support this as an option. How would we test it? We'd have to run all tests with this option on but that would generate an entire different set of snapshots - and we've run into problems with the non-deterministic nature of it. We respect object expansion so we've had experience with this - if a deeply nested object gets broken across lines because of a rule, a second printing of the file could produce a different result of the first printing. This caused problems because we re-printing files and staying the same is a core strategy to test the soundness of prettier)

jlongster on 19 Dec 2017

👍2

However, you don't respect jsx element original expansion, while the corresponding React.createElement calls would be respected, since it's an object literal - would you at the least be open to expanding that "existing expansion respect" to include jsx?

ljharb on 19 Dec 2017

Objects were respected mainly because there are a lot of cases where you are passing a large config-style object to something and frequently adding/removing things and you want it to stay the same always. I view JSX as more like function calls that should collapse, but I'd like to hear what others think. Personally I would be disappointed if it didn't collapse; I take advantage of this all the time by removing attributes and prettier cleans it up (makes it compact again).

React.createElement not collapsing is an unfortunate side-effect of treating objects special for a different use case. But I think it's OK because very, very few people manually use those functions, and the recommended way to write React is to use JSX. Do you all manually use React.createElement?

I'm not going rule out a specific request like that, we should hear what others think.

jlongster on 19 Dec 2017

👍2

I don't think it makes much sense to compare JSX with React.createElement.. those are different syntaxes, they should be printed with different mindsets. The fact that one is sugar to the other is irrelevant to the formatting IMO.

duailibe on 19 Dec 2017

As for objects, I find myself often having to delete line breaks to make it collapse again, which is annoying, to say the least.

Another data point to determinism is knowing that an object will break or not before considering the print width, is #2803. It will stabilize after the 2nd output, but it's still annoying to run prettier -> commit -> have CI complain at you.

duailibe on 19 Dec 2017

There's a lot to discuss for Prettier 2.0; could we move some of these conversations to more topical threads?

There's an issue to discuss disabling multiline collapsing at https://github.com/prettier/prettier/issues/3524.

I have also opened an issue to discuss telemetry/scraping at https://github.com/prettier/prettier/issues/3538

rattrayalex on 20 Dec 2017

👍2

Determinism as defined by @jlongster is what makes Prettier special and ultimately useful, IMHO.

gabssnake on 20 Dec 2017

👍4

Following up a bit on https://github.com/prettier/prettier/pull/3536#issuecomment-354206179, given the plugin system, it might be nice to namespace language-specific config options.

So instead of:

--single-quote true
--prose-wrap always

{
  "singleQuote": true,
  "proseWrap": "always"
}

Do something like:

--js:single-quote true
--markdown:prose-wrap always

{
  "js": {
    "singleQuote": true
  },
  "markdown": {
    "proseWrap": "always"
  }
}

taion on 28 Dec 2017

👍4

{
  "js": {
    "singleQuote": true
  },
  "markdown": {
    "proseWrap": "always"
  }
}

Agree with @taion that this could be handy in some situations
You could for instance have singleQuotes in JS, but prefer double with PHP...

--js:single-quote true
--markdown:prose-wrap always
Not sure about the CLI naming tho... 😕

MichaelDeBoey on 28 Dec 2017

:+1:, but some options (like indent and singleQuote) are shared between multiple languages.

j-f1 on 28 Dec 2017

Maybe it would be better to only make the distinctions in the docs, since those categories can be changed without notice as needed.

j-f1 on 28 Dec 2017

singleQuote was a bad example. Sorry. I meant more like proseWrap which is specific to markdown, and could e.g. be something defined by the markdown plugin.

So the idea would be to move stuff from global config options to plugin-specific config options where relevant.

taion on 28 Dec 2017

I guess that's more of a two-parter, then:

If we allow plugin-specific options, then we should make some of the existing options (like proseWrap) plugin-specific; these options should also probably be namespaced
Even for global options, it might be nice to configure them by language; this might take the same namespacing approach as the above, even though it's not exactly the same thing

taion on 28 Dec 2017

We should also keep in mind that JS, MarkDown, ... are default in the core, so for users it can maybe be confusing if we start talking about the "markdown-plugin", when in fact there is no real plug-in...

MichaelDeBoey on 28 Dec 2017

Yeah – it’s still nice to communicate that proseWrap is markdown-specific though.

taion on 28 Dec 2017

Even for global options, it might be nice to configure them by language

We can already do this with config overrides.

singleQuote: true
overrides:
- files: "*.php"
  options:
    singleQuote: false

azz on 28 Dec 2017

👍3

That doesn’t fully work for embedding, though, does it?

taion on 28 Dec 2017

@taion It does not. But it's important to make it clear that it's currently not possible to set different printWidth's in the same file.. that option is currently used on the final step (print doc as string). To be able to override it in anyway, we'd have to change some of the logic

duailibe on 29 Dec 2017

I'm a bit lost. @azz what's the reason to remove https://github.com/prettier/prettier/issues/1139 from the list when we have a really big fanbase as well as good reasons e.g to increase the searchability https://github.com/prettier/prettier/issues/1139#issuecomment-316096507 ?

StarpTech on 30 Dec 2017

what's the reason to remove #3503 from the list

Did you mean to link to a different issue here?

j-f1 on 30 Dec 2017

Oh, my mistake I updated it to issue https://github.com/prettier/prettier/issues/1139 thanks!

StarpTech on 30 Dec 2017

@StarpTech see https://github.com/prettier/prettier/issues/3503#issuecomment-352802184

azz on 30 Dec 2017

@azz that explanation for #1139 seems based on a flawed understanding of the request; i corrected it here

ljharb on 30 Dec 2017

Pretend I said trailingComma instead of printWidth. Currently that's a non-namespaced JS-specific option. Other languages have different rules around trailing commas that don't map to the JS options.

Perhaps something like that explicit namespacing for plugin options should be an optional thing. If you're just formatting JS, then --trailing-comma does what it does now. If you're doing, say, both JS and Python (somehow), then you'd have to perhaps do --js:trailing-comma and --python:trailing-comma, say.

taion on 31 Dec 2017

How about extracting the Flow parser to a Flow plugin, since Babylon can handle (almost?) everything, and it’s just a --plugin @prettier/flow --parser flow away if someone needs it. This avoids having to download two full copies of a JS parser. Plus, if babel@7 gets released before we do 2.0, we can move TS-ESLint-parser into a plugin too, additionally decreasing the download size.

j-f1 on 31 Dec 2017

I still think even mixing CLIs is too much. There should be a prettier-python and prettier-php CLI exactly for the reasons above. That API is a red flag for me and indicates that it's trying to do way too much.

jlongster on 1 Jan 2018

👍2

Maybe a better question is – what's the point of Prettier for Python?

I don't really want to use a Node tool as part of my Python build pipeline, all else being the same. It's not something that's going to be readily available in e.g. the Python Docker images that we use for CI. I think the same applies for most Python developers in general, and while the languages are similar enough, the people who know the most about Python AST manipulation/&c. aren't generally also going to be highly proficient in JS.

There's an ecosystem of Python projects for Python tooling, and while the ecosystem is not great, that's more due to underinvestment than to any problems with the language itself – but adding this barrier of having to know both JS _and_ Python AST manipulation is only going to make it harder to make Prettier for Python good.

So what are the potential benefits? To me they really seem like:

Reusing Prettier's handling for CLI, finding files, writing, &c.
Reusing Prettier's printing engine
Multi-parser support for e.g. markdown documents containing Python

But to each of those:

There are existing tools available for this in Python already; in general as with eslint-plugin-prettier or prettier-eslint, I'd think it would be easier from a Python POV to just pull in a flake8-prettier and never think about the Prettier CLI
@vjeux said the printing engine was relatively straightforward to port to Python
_This_ is the big one that requires some level of integration, but it's also perhaps not the most useful thing ever to most people

But from my DX perspective, pulling in Node into my Python build toolchain is sort of an anti-feature. I was picturing something like the core of prettier-python being implemented in Python (and e.g. reusing libs there like astor to handle parts of the AST printing), with some JS glue around it for integration into Prettier proper, but with most users going through a pure-Python path with something like a flake8-prettier that does in fact reimplement the printing logic.

@czosel @mgrip How does this look on the PHP side? Do you lose anything by writing prettier-php in JS rather than in PHP?

taion on 1 Jan 2018

I don't really want to use a Node tool as part of my Python build pipeline, all else being the same.

We could use something like pkg to package Prettier and prettier-Python into one executable for use with pip, avoiding installing Node.

while the languages are similar enough, the people who know the most about Python AST manipulation/&c. aren't generally also going to be highly proficient in JS.

Fortunately, there are some people, and most of the bug-fixing effort is not going to involve the Python AST anyway.

There's an ecosystem of Python projects for Python tooling, and while the ecosystem is not great, that's more due to underinvestment than to any problems with the language itself – but adding this barrier of having to know both JS and Python AST manipulation is only going to make it harder to make Prettier for Python good.

I would guess that the vast majority of people who use Python linting tools (and probably JS ones, too) will never actually open a PR to add a feature or fix a bug. This isn’t a bad thing, it’s just that people have other things to do.

@vjeux said the printing engine was relatively straightforward to port to Python

Can you link to that? I’m wondering what the context was.

That would be a bad idea IMHO, since we would have to maintain two versions of the printer, meaning that we would need someone proficient in both Python and JS to fix bugs or add features.

[Multi-parser support] is the big one that requires some level of integration, but it's also perhaps not the most useful thing ever to most people

It’s still pretty awesome, and it makes it possible to copy-paste from your project’s docs directly to your codebase without running into as many formatting issues.

j-f1 on 1 Jan 2018

👍1

It's not so straightforward with pkg since you'd have to deal explicitly with multi platform. Plus that does not so much to solve questions of integration into existing tooling.

Ref https://github.com/prettier/prettier/pull/3349#issuecomment-348348159 on porting.

The issue isn't the "printer", it's the "doc printer". For JS, compare:

Printer: https://github.com/prettier/prettier/blob/1.9.2/src/printer.js, >5000 LOC, frequent changes, JS-specific
Doc printer: https://github.com/prettier/prettier/blob/1.9.2/src/doc-printer.js, <500 LOC, not many changes, of which almost all recent ones relate to markdown (there's somewhat more for comments, but much of that is JS-specific, e.g. https://github.com/prettier/prettier/blob/1.9.2/src/comments.js#L24-L37)

In some sense that to me is a tech argument against folding in Python support here. Markdown support required changes to the "core" code. Python support likely will as well, given e.g. Python requiring two spaces before same-line comments, &c.

Meanwhile on the other end, there is a canonical representation of Python ASTs that lives in Python, into which tons of Python tooling integrates – and this representation isn't so neat to dump into JSON that can be loaded by JS.

I agree that most engineers shouldn't need to think about tooling, but if you restrict the community of people who can participate, _and_ you incur significant tradeoffs in doing so, _and_ you ditch an ecosystem of tools that are already available, then you're not in a good spot.

taion on 1 Jan 2018

@taion you seem convinced that the best way forward is to write it in python. My recommendation would be to spend your time setting it up that way and working on it & convince people to join your project. Code wins arguments :)

vjeux on 1 Jan 2018

👍2

Mostly I just want a code formatting tool that works as well for Python as Prettier currently does for JS ;) Ideally I'd prefer not to write it for myself, no. It should just be yapf, but unfortunately yapf doesn't work very well.

My impression here, though, is that most of the people who have contributed to the Prettier for Python effort have been more familiar with JS than with Python, and aren't familiar with Python conventions, such as how comment formatting should work, or with much of the existing Python ecosystem.

Is it clear to you that the best approach is to dump the canonical Python AST into JS (avoiding issues like Python numbers not all being representable in JS, &c.)? The alternative isn't "do everything in Python" so much as perhaps "do the AST processing in Python and expose a different format to Prettier that's more digested".

But I do see this as more of an all-or-nothing thing. A Node prettier-python seems somewhat less compelling than a prettier command that can handle a mixed codebase. I could see myself using the latter. I could also see myself using the former if it were very good, but it would make me scratch my head a bit – and I imagine you as well?

taion on 2 Jan 2018

👍1

The doc objects are currently all JSON-compatible (except the placeholder: Symbol("cursor") in cursor), and as such, we could write the parsing and doc-building infrastructure in Python, then synchronously call out to it in a small JS plugin. However, we would still need a method of representing the AST in JSON, since it gets round-tripped through Prettier core so people can use their own compatible parsers/printers.

j-f1 on 2 Jan 2018

You'd just make the parser emit something that can be trivially transformed into the doc objects, and have the printer be trivial.

The Python AST itself is not really JSON compatible without massaging, even in the current exported form (https://github.com/prettier/prettier-python/commit/479ecce524ecbb4e6fc7fc1585a4417aca9f29a7#r26507439) – since any JSON-compatible representation of the AST is essentially arbitrary, it's ~equivalent to do more of the current "printing" work in the parser, since you can't really plug in a different printer anyway given the (as noted) essentially arbitrary AST representation.

So in the near term – just make the Python part of the parser script do more work. Pure Python integration can live down the road, though there's still a +/- thing on additional complexity in the core doc printer required to really support Python well – but that can be deferred.

taion on 2 Jan 2018

Can we keep this thread on the topic of Prettier 2? There's already an issue for discussing the Python integration model here: https://github.com/prettier/prettier-python/issues/2.

azz on 2 Jan 2018

👍4

We could revisit the trailingComma option too.. Right now we don't really print _all_ trailing commas (see #3311, #3313 and #3662).

We could either rename the all option to something else and not change anything in behavior.. or change the behavior to start printing trailing commas in those cases.

duailibe on 8 Jan 2018

On #3311, pragmatically, there's little reason to emit trailing commas that aren't legal syntax. Babel 6 can handle that trailing comma as well, but I don't think that means anybody would want it, even if they're asking for "all" trailing commas.

taion on 8 Jan 2018

there's little reason to emit trailing commas that aren't legal syntax

Prettier will _never_ (intentionally) emit code with illegal syntax. The point is trailing commas _are_ allowed after rest parameter/property in TypeScript, not in ES (i.e. ~Babel 6/7 will give a syntax error~ EDIT: Babel 6 supports it, Babel 7 throws an error).

I don't think I understand what you mean.

I don't think that means anybody would want it

There have been about 5 or 6 issues on trailing commas after rest param/prop.

duailibe on 8 Jan 2018

Babel handles that trailing comma by default: https://babeljs.io/repl#?babili=false&browsers=chrome%3E62&build=&builtIns=false&code_lz=MYewdgzgLgBA3jAhgGhgI1QOm8GBfGAXhgA8AoUSWBAE1QFMtsAzVA4koA&debug=true&circleciRepo=&evaluate=false&fileSize=false&lineWrap=false&presets=stage-3&prettier=false&targets=&version=6.26.0

It used to not, but they added it back.

taion on 8 Jan 2018

Ah gotcha. I was talking about the version we use in Prettier: prettier playground

EDIT: which is Babel 7 and looks it doesn't handle: babel 7 repl

duailibe on 8 Jan 2018

@taion babel used to, we removed because it was a spec violation, but then added it back because it was a breaking change. We're finally removing support in babel 7.

Trailing commas after spreads are fine, trailing commas after a rest object/array is _not_ fine. This includes trailing commas in function formal arguments -- it's fine, since ES2016, as long as the preceding argument is not a rest argument.

Jessidhia on 9 Jan 2018

👍1

What about moving the TypeScript and Flow parsers to external plugins? That would decrease the size of the core Prettier package a lot, and if we move to Babel 7 at the same time, those parsers would become unnecessary.

j-f1 on 21 Jan 2018

I think we should keep tsep in core at least until we switch to babylon.

azz on 21 Jan 2018

Summary:

Things that appear to have consensus:

#2691: Default the CLI glob to "**/*.{js,ts,...}".
#2846: Replace the --parser option with --language.
#68: Change default value for trailingComma to "es5".
^{(I’ve unlocked and reopened the issue to indicate that we’re considering it again and allow people to discuss)}
#4097: Remove deprecated options (--flow-parser and --parser postcss).
#4102: Change the default value for singleQuote to true
[no issue]: Remove exitCode: 2 from CLI, or figure out when should we apply exitCode: 2 as it's very unclear now.
_{feel free to edit this to add new features}

Things that need consensus:

#838: Consistently add quotes to object keys.
#3847: Add the space after function in function () { ... }
#3845: Add the space before ( in function foo () {}
#1080: Use single quotes in JSX.
#3919: Drop Node v4.x support (Maintenance LTS End: April 2018).
#2884: Remove the default parser.
#4103: Remove the TypeScript and Flow plugins, and add a --language typescript option that enables Babylon’s typescript option and disables its flow option.

j-f1 on 23 Jan 2018

👍4

Looks good except for node v4 compat. Was chatting with @vjeux and we think we shouldn't force people to upgrade versions, especially since Prettier is often run in CI.

azz on 23 Jan 2018

👍4 ❤1

Just a thought, would it be better to make prettier not require node 4 but instead transpile the version published to npm? That way you can use arrow functions and other ES6 niceties in the codebase but still allow people to use it on CI servers with older dependancies.

aboyton on 29 Jan 2018

👍3

Yeah I was doing that in #3712 but I lost momentum.

azz on 29 Jan 2018

🎉1

I know it's been striked out in the OP, but I would like to bring up "space after function keyword in anonymous functions" again. #3847. Now that it's been clarified what it is all about (i.e. totally unrelated to "space after function name in declarations"). I vote for making that change in 2.0. Especially since @ljharb's rule is so simple:

"function keyword", "space", "optional name", "argument list".

lydell on 1 Feb 2018

👍4

Proposal: Add a temporary prettier2 option in the next release that would allow people to test out breaking changes and give us feedback, then 🔥 it in 2.0. We could add breaking changes to it at any time between now and 2.0, allowing us to stay agile. WDYT?

j-f1 on 1 Feb 2018

@j-f1 I do not think that this is a good solution, many people can use this option for a very long time or simply forget it then delete it, which will give rise to many issues (when people wait one output, but get other, because we forgot remove option). Better use alpha/beta/rc IMHO.

alexander-akait on 1 Feb 2018

👍4

Yeah, that’s a better solution.

j-f1 on 1 Feb 2018

Giving my shoutout to #1420 :) Functional patterns are so popular in codebases.

RohovDmytro on 27 Feb 2018

👍1

In the spirit of keeping everything in the .prettierrc file, would you guys consider the possibility of allowing a "write": true config option so that the only thing you need to run is prettier instead of prettier --write?

zaynv on 3 Mar 2018

👍7

Or just making the write the default option :)

lipis on 3 Mar 2018

👎5 👍3

Some of the discussed issue from here we could create separate issues and mark them with 2.0 milestone

lipis on 3 Mar 2018

R.e. prettier defaulting to write, I don't like that at all. We should remain a good UNIX citizen and read from stdin by default and write to stdout.

With putting CLI options in the .prettierrc file, there are two issues:

The config file is shared between the node API and the CLI, so we'd have to scope it by calling it cliOptions.
There's very likely a chicken and the egg scenario with loading the config file before knowing all the CLI arguments. The argument parsing and precedence is already very complex in Prettier, and I wouldn't want to add more complexity if it can be avoided.

azz on 4 Mar 2018

👍6

I think we should default to --list-different, and add a --stdout option, since concatenating all of your project’s files together isn’t what most people want by default. ^{[citation needed]}

j-f1 on 4 Mar 2018

👍2

If the data is coming from stdin, it makes sense that stdout would be the default. If however you are dealing with files, stdout almost never makes sense.

As much as I like the idea of simplifying things, the default should probably NOT be write, as it would violate the principle of least astonishment/surprise.

ericanderson on 5 Mar 2018

👍4

I agree with @j-f1 that concatenating multiple files as the default really don't make sense. I'm personally in favor of --write as a default but if we need to keep more back compatibility, I'm happy with defaulting to --list-different. Also if --write is the default it could be conditionally disabled when stdout is a pipe to prevent breaking tooling integrations.

Further discussion: https://github.com/prettier/prettier/issues/4129

nickmccurdy on 14 Mar 2018

About #838, this thread might be useful https://github.com/standard/standard/issues/791 + stats on ecosystem impact.

2691 - CLI defaults to...

Probably best would be src/, the tests and lib/. I believe that most of the repos is already using this convention.

As about extracting/removing not needed deps and parsers would be really great! It was suggested to be such as @prettier/plugin-js, but i think it will be better to be just the name of the language/parser @prettier/javascript, @prettier/markdown and etc.

Use single quotes in JSX.

Against. But yea, some "way" may be good.

As about the spacing problem of #3845 and #3847.. I'm with @AirBnB.

const x = function () {};
const y = function foo() {};

tunnckoCore on 4 Apr 2018

Proposal: Let's only make CLI changes in 2.0. No option defaults changes.

What if the CLI worked more like ESLint?

# Print help
eslint
prettier

# "Lint" all files in `.` with recognized file extensions
eslint .
prettier .
# In prettier's case, this replaces --list-different

# Fix
eslint . --fix
prettier . --write

# stdio
# don't think eslint can be used over stdio
prettier --stdin-filepath input.js < input.js > output.js
echo 'test' | prettier --language javascript
# perhaps we should get rid of --language and --parser, though
echo 'test' | prettier --stdin-filepath test.js

# or should we have sub-commands?

# help
prettier

# list different
prettier list-different FILES_AND_DIRS...

# write
prettier write FILES_AND_DIRS...

# stdio
prettier stdio < input.js > output.js
# --stdin-filepath replacement?
prettier stdio input.js > output.js

# we could have global options, and specific options for every sub-command

If the user wants to run Prettier on files with unknown file extensions, they have to make a config file mapping file extensions to languages/parsers (just like is already possible).

lydell on 1 May 2018

IMO being able to do some-command | prettier --language js > foo.js is pretty valuable.

j-f1 on 1 May 2018

That would be either of these with my ideas above:

some-command | prettier --language javascript > foo.js (the same)
some-command | prettier --stdin-filepath tmp.js > foo.js ("hack" to show that input is JS)
some-command | prettier stdio --language javascript > foo.js
some-command | prettier stdio tmp.js > foo.js ("hack" to show that input is JS; tmp.js is only read if no stdin)

lydell on 1 May 2018

Btw, have there been any discussions about having language-/plugin-specific options? Such as --js-parser flow, --css-parser less, --python-version 2?

lydell on 1 May 2018

Did you mean https://prettier.io/docs/en/plugins#options?

ikatyang on 1 May 2018

👍1

elm-format’s CLI is pretty nice.

# Lists all found files and prompts whether you want to overwrite them.
elm-format Main.elm src/

# Automatically answers "yes" to the prompt.
elm-format Main.elm src/ --yes

# Basically `--list-different`.
elm-format Main.elm src/ --validate

We should look at gofmt and refmt too for inspiration.

lydell on 2 May 2018

gofmt seems very similar to Prettier:

# print all files formatted to stdout, just like prettier
gofmt main.go src/

# --list-different
gofmt -l main.go src/ 

# --write
gofmt -w main.go src/

However, I think that the default behavior (print everything to stdout) is pretty useless.

lydell on 2 May 2018

👍2

elm-format Main.elm src/ --validate

I'd be great if Prettier implemented --validate too. It can work the same way as --list-different, but have a slightly more humane stdout. This would include printing the list of all checked files with ticks and crosses and some hints like _Found 4 files are not formatted. Did you forget to run Prettier?_ Exit code should be 1 if anything is not formatted, just like it works for --list-different already.

This is currently done by prettier-check (which is a shallow wrapper for Prettier) and I'm using it in CI for all my projects. It'd be great if the same helpful execution mode became a part of Prettier at some point to keep package.json cleaner and shorten the project setup process.

kachkaev on 2 May 2018

👍1

Not sure what you mean. This is how --validate looks to me:

❯ elm-format elm --validate
[{"path":"elm/View.elm","message":"File is not formatted with elm-format-0.7.0-exp --elm-version=0.18"}
,{"path":"elm/Main.elm","message":"File is not formatted with elm-format-0.7.0-exp --elm-version=0.18"}
]

lydell on 2 May 2018

@lydell ah, you're right – I thought --validate in elm-format would work differently based on the name 😅 This does not cancel my desire to have the functionality of prettier-check built in into Prettier. I'm missing human-readable stdout when running --list-different in CI and before git commit, so have to use an extra dependency. Option name --validate or --check could be suitable for this.

kachkaev on 2 May 2018

@duailibe Do you know how refmt works?

lydell on 2 May 2018

@lydell I think the default is to output to stdout and you can use --in-place to write the file. I don't think it has --list-different option like prettier

duailibe on 2 May 2018

In other news https://medium.com/the-node-js-collection/april-2018-release-updates-from-the-node-js-project-71687e1f7742 maybe reopening the #3919?

lipis on 4 May 2018

👍2

node 4 being out of LTS doesn't change that many people still use it.

ljharb on 4 May 2018

👍2 👎1

May I suggest that 2.0 gets rid of --with-node-modules and instead relies on having !node_modules in .prettierignore?
It seems to me a bit more in line with other .fooignore files I have seen around.

Additionally, if there are other files/folders ignored by default (https://github.com/prettier/prettier/issues/4547 prompted me to write this comment), there would be no temptation to add new --with-<xyz> flags as adding !<xyz> would universally un-ignore them (I haven't checked if the ! syntax already works).

astorije on 25 May 2018

👍5

@ljharb it also means that they should move to at least the next LTS - we have enough LTSs. And that's one of the brilliant aspects of Node.js and Ubuntu.

Tools and such things should be leader of moving forward. Users won't move until they are _a bit forced_ to do so. In case of JavaScript, version upgrade is pretty great thing - better performance, better features, lower codebase and ton more.

Not to mention that such tools are for the dev machine/env while developing their codebases, not their actual code. They still can test their codebase on older JS versions. Most easier thing is to install v6-8-10 so to work the development tools and release or use Babel/TS to compile to lower versions.

The train of dropping v4 was started anyway.

tunnckoCore on 25 May 2018

👍2 👎1

@olstenlarck i totally agree that people on an EOL node should upgrade - but libraries and tools dropping support for the node they're on makes it harder for them to upgrade, not easier.

On the contrary - users upgrade aggressively unless it's hard. Nobody needs to be forced to use a newer, faster, shinier node - but they definitely might need to be forced if all their tools no longer work on the newer version of node, or if the node upgrade is much much riskier because they have to update deps at the same time as node.

ljharb on 26 May 2018

👍2 😕1 👎1

I would really appreciate support for html formatting and in style for specific web frameworks --language html --language html-angular --language html-vue. I could work on a PR to provide the base.

StarpTech on 11 Jun 2018

👍4

As mentioned in my last comment I'm working on a project called https://github.com/StarpTech/prettyhtml which is able to format HTML5 and HTML5 non-compliant template syntaxes like Angular. It's heavily under development but any contribution is welcome. I follow the idea that we can merge it with prettier someday.

StarpTech on 24 Jun 2018

👍4

@StarpTech we have a PR #4753 now if you want to take a look and why not getting more involved..

lipis on 27 Jun 2018

👍1

@lipis thanks for the pointer but I think my project follows different goals and it wouldn't be easy to get a connection.

I want to provide a formatter which is able to parse (fork of parse5) any template which is a subset of HTML5 e.g Angular, Vuejs.
I rely on the fantastic rehype ecosystem which make it very easy to split your transformer in multiple packages with a consistent interface.

e.g I can take rehype-format as reference project. All the efforts related to whitespace handling was already implemented by rehype-minify-whitespace. AST to HTML is already done in rehype-stringify so in best case I only have to fork some projects and implement my own ruleset 😄

StarpTech on 27 Jun 2018

@StarpTech IMHO, it looks wrong, why?

Vuejs and Angular and can modify template syntax (it is incompatibility with HTML and they already done this) - better use separate parser for each template syntax.
You solution not respect print width and embedded content like script/style and etc stuff.
Support forks cost a lot of time and effort.

We can switch on rehype if will have problems with parse5. The most important thing now is to accumulate as many tests as possible.

alexander-akait on 27 Jun 2018

Hi @evilebottnawi

Vuejs and Angular and can modify template syntax (it is incompatibility with HTML and they already done this) - better use separate parser for each template syntax.

I use a customized parser which is aware of that. It can already parse attributes and elements case-sensitive and is compatible with all angular and vue syntaxes.

<!-- Vue -->
<form v-on:submit.prevent="onSubmit"> ... </form>
<!-- Angular -->
<div *ngFor="let hero of heroes">{{hero.name}}</div>

...

You solution not respect print width and embedded content like script/style and etc stuff.

My draft is heavily in development but I currently work on respecting the print width.

Support forks cost a lot of time and effort.

Sure, but the projects are very solid and I don't have to maintain it I rely on the existing code to adapt it to my requirements.

StarpTech on 27 Jun 2018

We can switch on rehype if will have problems with parse5. The most important thing now is to accumulate as many tests as possible.

rehype has nothing to do with parse5. Rehype provides a general abstraction of how to work with AST in HTML. There are packages for htmlparser2 and parse5 for and more.

StarpTech on 27 Jun 2018

@StarpTech hm, you are right, rehype use parse5, but 4 version, we use 3 :smile: (need update)

alexander-akait on 27 Jun 2018

@evilebottnawi and would be very awesome to use the template parser from angular and vuejs to create a compatible HAST tree to format HTML, Angular and Vuejs Syntaxes in one fashion 😄

StarpTech on 27 Jun 2018

Can we move the HTML discussion to another thread?

Excited by the energy; I've been wanting a capable prettier for HTML for a while now!

rattrayalex on 28 Jun 2018

👍3

Just as a reminder to my previous post. https://github.com/StarpTech/prettyhtml has a good state and can be evaluated. I appreaciate any help and feedback. It use prettier for embedded content. What's the difference between the WIP PR https://github.com/prettier/prettier/pull/4753?

Can parse case-sensitivity and custom self-closing elements. This means we can format any known superset of HTML5 templates e.g Angular, Vue etc..

StarpTech on 8 Jul 2018

Hey guys, this v2 looks super promising! It already solves the main issues we had with current stable version of Prettier. Do you have any idea when we could expect it to be out?
In the meantime, if I decide to use the v2 "beta", what would be the recommended way to install it?

testerez on 2 Aug 2018

In the meantime, if I decide to use the v2 "beta", what would be the recommended way to install it?

Unfortunately, there is no v2 beta at this time.

j-f1 on 3 Aug 2018

I would really like Prettier to just format all files in the cwd that it supports. Currently I have to construct a glob in every project, which is highly non-trivial when it comes to dotfiles like .travis.yml and other config files:

`prettier '**/{*.{js?(on),ts,y?(a)ml,graphql,md,scss},.*.y?(a)ml,.*.json,.prettierrc,.stylelintrc}'`

Also, +1 for trailing commas. I used to hate them, but after our team with mostly Golang background voted for them and I used them for a few weeks, I now (months later) cannot live without them anymore. So much easier to move lines around.

felixfbecker on 18 Oct 2018

👍16 ❤5

I vote for double quotes over single. I know this is an uphill battle, here's my 2c:

In non-js environments, double quotes usually results in the intended behaviour, namely similar behaviour to JS backtic.

Some examples:

JSX uses Double
JSON spec uses Double
Python: users overwhelmingly use Double (driven by the PEP Docstring convention) - https://stackoverflow.com/questions/56011/single-quotes-vs-double-quotes-in-python
Shell Scripts: usually double quotes is the intended behaviour (variable expansion, array access) - https://stackoverflow.com/questions/6697753/difference-between-single-and-double-quotes-in-bash/42082956#42082956
PHP: again, double quotes is predominantly used as it evals variables like the JS backtic ` - https://stackoverflow.com/questions/3446216/what-is-the-difference-between-single-quoted-and-double-quoted-strings-in-php/3446286#3446286
Ruby: again, double supports string interpolation & escaping - https://stackoverflow.com/questions/6395288/double-vs-single-quotes/6395332#6395332

My main concern is about tempering expectations outside of the JS world. Developers mostly use a handful of languages, by making a habit out of using and reading the common use-case across languages, it reduces the learning curve and avoidable mistakes when branching out.

arguments FOR single quotes I've heard are:

single looks nicer
single doesn't require the shift key
single is gaining popularity in JS

(none of these argue for it's utility over double)

My responses:

subjective and inarguable
can be solved using an external tool
popularity is not necessarily indicative of the utility of something. The tools listed only cover JS. I chose the above examples as Prettier is actively adding support for those languages, and a tool used across programming languages should be concerned with trends across all tools they support.

I was in the single quote camp until I ran into issues learning Bash scripting. To be honest, I like the current method Prettier uses where it reduces the escaped chars, it seems to make most people happy.

Maybe I just need to chill out.

Thanks for your great work!

Edit
@ljharb That's fair, I'm just going off what I've seen (which is not definitive) and that is: people wanting what double does (in whatever lang, be that interpolation/expansion etc) but using single out of habit.

jthegedus on 26 Oct 2018

👎6 👍2 ❤1 🎉1

@jthegedus in any language where double quotes are interpolated and single aren’t, the best practice I’ve seen is to always use single unless interpolation is needed, for perf and to avoid accidental interpolation.

ljharb on 26 Oct 2018

👍4

@jthegedus Great points. I've been using single quotes, but I think I'll actually switch back to get consistency with JSX's double quotes.

@ljharb As far as I'm aware, the performance of single and double quote strings in JS is equivalent. Backticks have such a minimal overhead that I wouldn't mind defaulting to them (if JSX gets that syntax supported first, for consistency).

nickmccurdy on 26 Oct 2018

👍1

@nickmccurdy oh sure, i wasn’t making a claim about JS there. (Altho the airbnb linter config prohibits both backticks without interpolations and interpolation-like syntax in normal strings, to avoid accidents)

ljharb on 26 Oct 2018

👍1

@jthegedus I totally agree with you and was thinking to put that somewhere for a long time.

Ha. Didn't follow up for a long time. I'm considering to switch back to double quotes for a whole year already. Always thinking about that how JS style is totally different than most of the languages - php, html/jsx, python, css, json and what not. Most of the languages are using double quotes and 4 spaces.

I really don't remember if it was a problem in the beginning when I started, but yea, single quotes are more easier.
Now, since the inception of Prettier, I really don't care what I'm using because my flow is like that that everything is applied (Airbnb eslint + Prettier) on file save (autosave on plus the habit to do ctrl+s every 30 seconds or so) and on pre-commit. So I definitely don't care.

I still can't understand why most not using ESLint's --fix by default and/or Prettier's --write. It's just not make any sense to me. The only argument that i'm hearing is "because the diffs, noob" - wtf... ANd yea, don't get it. Yes the diff MAY (depending on that if you are applying it on existing project) be huge. But that will be OONLY ONCE - and eventhough, why you should care about it?! You prefer to manually apply a fix for each error one by one?! Errmm, don't think so. So, after that one diff, all next things won't have big diffs, because you and your team are automatically applying that style+format on editor save, OR at least have as a pre-commit hook.
So, it's impossible in git to appear something broken or incorrect.

It just freaking me out. I don't get it.

tunnckoCore on 26 Oct 2018

🎉2

I updated the OP since it had gotten pretty out dated.

Here's my suggestion:

Release 2.0 with only one change: trailingComma: "es5". Better git diffs.

Release 3.0 with only breaking CLI changes, once we've figured out how it should work.

Release 4.0 with other formatting changes, if we ever agree on something.

(To me, switching from single to double quotes – a purely stylistic choice with no benefits in either direction – at this point will only cause unnecessary churn.)

lydell on 26 Oct 2018

👍3

@lydell I know the post is nearly a year old and I'm late to the game, I just wanted to represent the other side of the single/double discussion. I like the current implementation more than the other options, but if a change _was_ occurring that's my argument.

Apologies all for the notifications :stuck_out_tongue:

jthegedus on 26 Oct 2018

👍1

Release 3.0 with only breaking CLI changes, once we've figured out how it should work.

IMO this should be grouped with 2.0. People might not want to upgrade a major version unless it has some fancy new features. Also, since changing the default for an option is easy, we can do it at the same time as the CLI changes.

Also, how about the space-after-function change? (#3903)

j-f1 on 26 Oct 2018

👍5

Release 2.0 with only one change: trailingComma: "es5". Better git diffs.

Can someone remind me, why not all?

lipis on 26 Oct 2018

👍1

@lydell deterministic object printing (ie, ignoring input newlines) would also be fantastic. Not sure if anyone's working on that; I may try to take a crack at it next week if not.

rattrayalex on 26 Oct 2018

Check out my compromise at #5205 @rattrayalex. Is that sufficient or should we switch to just AST-based printing for objects?

j-f1 on 26 Oct 2018

@j-F1 oh nice, hadn't seen that! I still think it'd be great to shoot for AST-based personally. If we don't get to it, though, not the end of the world.

rattrayalex on 26 Oct 2018

👍1

Can someone remind me, why not all?

Because we don't want to turn es5 code into es6 code by default.

IMO this should be grouped with 2.0. People might not want to upgrade a major version unless it has some fancy new features.

Yeah, but I'm worried it'll take too long then.

deterministic object printing

Sounds like #2068 (PR: #4685).

lydell on 26 Oct 2018

👍2

Please add https://github.com/prettier/prettier/pull/3903

kirillgroshkov on 30 Oct 2018

👍1

Should we perhaps start a 2.0 branch and iterate on breaking changes while we continue to provide new features on 1.x?

j-f1 on 6 Nov 2018

👍2

@j-f1 any word on a prettier 2.0 branch?

rattrayalex on 1 Feb 2019

A comment way above mentioned dropping Node v4 because it was about to enter EOL; the tooling around eslint has already done so so it's starting to affect prettier somewhat (the @typescript-eslint/parser PR had to do some monkey patches IIRC).

Based on the current time it might also be time to drop Node v6 or even v8. Maybe not necessarily "guarantee it won't work on v6", but "not guarantee it'll stay working on v6". Not doing so might cause problems faster than it did in Prettier 1.

Jessidhia on 1 Feb 2019

👍8 👎1

Agreed - let's discuss in https://github.com/prettier/prettier/issues/3919, which is linked in the prettier 2.0 milestone.

rattrayalex on 1 Feb 2019

When adopting Prettier I try to be as open as possible to its choices & not override too much. Currently, for my own purposes I'm happy to just enable trailingComma: 'all' (to reduce Git diffs) and leave the rest as it is.

Enabling consistent quoting would be a huge issue for me, though, especially with no way to override it. This is because changing one line may trigger changes in many more, especially for large object literals.

Small Git diffs don't just help people visually, they also reduce merge conflicts when multiple people modify code in similar places. While it's fine ESLint has rules allowing such enforcement if someone dislikes the status quo visually, I think an opinionated tool like Prettier should strive to minimize formatting changes needed after making a small change in the code.

The only argument for consistent quoting that I've seen is "it looks better" which is subjective. There are many more objective arguments against it so please don't do it!

mgol on 16 Feb 2019

👍8

Would this be the proper issue to voice a desire for something like a quoteStyle and possibly a jsxQuoteStyle option? I would love to have the option to use backticks everywhere in my code. It looks like some of the comments point toward a config that reduces the unnecessary changes in a commit (which is absolutely valid).

I tend to be of the mindset that I want my setup to have rules that eliminate as much of a mental tax as possible. So I always use semi, arrowParens, etc.

Is reading code with a different config hard? No. I simply prefer to be able to scan the code and to think about what really requires thought :)

Jared-Dev on 18 Mar 2019

❤2 👍2 🚀1

@Jared-Dev this has been suggested before #54

duailibe on 18 Mar 2019

👍2

Right, however, this is a thread about 2.0 which is where personally I would see a shift towards something like this making sense.

Regardless, this is something I'd love to see come into the next version of prettier :)

Jared-Dev on 20 Mar 2019

👍1

Being a proponent of Airbnb's style guide, it'd be great to see both trailingComma and singleQuote enforced by default.
I'd also suggest defaulting arrowParens to always, and for the exact same diff benefit that you get from trailingComma (adding args and then having to add the parens back in).
By far the biggest conflict that currently exists between Prettier and Airbnb's style guide is parentheses-wrapped multiline expressions. And with Airbnb's style guide being so popular, it seems like it'd make sense to provide an option for this. See the problem here, noting that ESLint has no intention of fixing it. And Airbnb's reasoning is sound logic, imo. This feature was considered, and has actually been waiting on me, but I just haven't found the time yet.

jabacchetta on 27 Aug 2019

👎4 👍1

I personally don’t like singleQuote, so I’d say keep that as false by default.

I prefer arrowParens set to avoid.

I also prefer useTabs set to true, because, like I said on Twitter, tabs _are_ the superior choice.

ExE-Boss on 27 Aug 2019

😕9

I personally think that since React is so popular and Prettier forces JSX to use double quotes, the default should stay as double quotes for consistency.

nickmccurdy on 28 Aug 2019

😕3 👍3 👎1

To be clear, the Airbnb config requires single quotes for JS and double quotes for JSX.

ljharb on 28 Aug 2019

👍3 👀2

@ljharb thanks for feedback, update first issue about this

alexander-akait on 28 Aug 2019

Can we conduct telemetry or ask users to share their configs somehow? If there are settings that a supermajority of users are choosing, we should probably set those as the default (and a github issue thread is not the best way to collect this data).

A google form listed prominently in the readme and tweeted & pinned might be enough?

rattrayalex on 31 Aug 2019

👍12

I got use to having extra spaces after parenthesis like
function( valu )
I thought you'd be able to add your own regex search and match kind of expressions.
(.*$)(.*)(.*$)
and to replace
$1 $2 $3
with groups for making replacements.
If this is already possible please direct me to a documentation example for customization of formatting.
If this is not possible please consider this as a suggestions for a future release.

MasterJames on 9 Sep 2019

👍1

I don’t think that would be a good idea since you could unintentionally break complex syntax; however, if you really want to, you could run a regex replace over your code after running Prettier.

j-f1 on 9 Sep 2019

👍1

I gotten use to most of these except extra space before a closing function bracket.
https://github.com/mrdoob/three.js/wiki/Mr.doob's-Code-Style%E2%84%A2

If there is a way to add space to function parenthesis I would feel at home with my code formatting.

MasterJames on 13 Sep 2019

I proposed implementing #3806 in a major version bump, so it probably should get added to the list here.

0az on 22 Oct 2019

👍4

Sorry for the pressure but I really hope a major release will come soon with the following:

completely drop support for old Node.js versions
consider "breaking" dependency updates, rather than relying on old dependency versions to avoid breaking changes
consider any other breaking changes that could be done with very limited controversy

Relying on old dependency versions makes the update increasingly more difficult over time. Supporting old Node.js versions makes this even worse. This seems to be a major diversion of time and attention that could be used for improvements and fixes.

My understanding from https://github.com/prettier/prettier/pull/6748#issuecomment-548494694 is that the new release should be coming in January 2020, with support for Node.js pre-10 removed.

Can someone from @prettier/core confirm?

Is there anything special that outside contributors such as @fisker and I should do to propose breaking or potentially breaking changes for 2.0?

P.S. Should this be discussed in a new issue? Should I raise a new issue to discuss this?

/cc @lydell @fisker @prettier/core

brodybits on 31 Oct 2019

👍6 😄1

@prettier/core

lydell on 31 Oct 2019

Can we pin this issue as well?

I think it could really help discussions with other projects, such as tildeio/simple-html-tokenizer#74.

brodybits on 6 Nov 2019

👍1

I crawled GitHub a bit and found out:

| master:.prettierrc | count |
| -------------------- | ----- |
| not json | 57 |
| singleQuote: false | 13 |
| singleQuote: true | 257 |

| master:.prettierrc.json | count |
| ----------------------- | ----- |
| not json | 7 |
| singleQuote: false | 2 |
| singleQuote: true | 30 |

Total repos: 2648
3 Queries made and merged: "stars:>=10", "language:JavaScript", "language:TypeScript"
(1000 repos per query)

| primaryLanguage | count |
| ---------------- | ----- |
| TypeScript | 1000 |
| JavaScript | 1000 |
| null | 113 |
| Python | 89 |
| Java | 68 |
| Go | 58 |
| C++ | 44 |
| CSS | 25 |
| HTML | 25 |
| Swift | 24 |
| C | 24 |
| Shell | 22 |
| Ruby | 19 |
| PHP | 19 |
| Objective-C | 15 |
| Jupyter Notebook | 14 |
| C# | 10 |
| Vim script | 10 |
| Kotlin | 10 |
| Rust | 9 |
| Vue | 9 |
| Scala | 4 |
| CoffeeScript | 4 |
| Lua | 4 |
| TeX | 3 |
| Dart | 3 |
| Haskell | 3 |
| Objective-C++ | 3 |
| Assembly | 2 |
| Elixir | 2 |
| Clojure | 2 |
| Perl | 1 |
| OCaml | 1 |
| Standard ML | 1 |
| Crystal | 1 |
| Batchfile | 1 |
| Rascal | 1 |
| V | 1 |
| Dockerfile | 1 |
| Julia | 1 |
| Makefile | 1 |
| Emacs Lisp | 1 |

If you want, I could publish a repo for the crawler tomorrow ^^

Shinigami92 on 9 Nov 2019

@Shinigami92 What about singleQuote: undefined?

That resolves to singleQuote: false.

ExE-Boss on 9 Nov 2019

It seems like this also doesn't account for projects using the default Prettier config with singleQuote: false. It would help to check projects with prettier in package.json, but still excludes users that only use Prettier via their editor globally.

nickmccurdy on 9 Nov 2019

👍2

It should be noted that any review of current prettier configs obviously excludes those who have chosen not to use Prettier (due to missing settings), even if they'd like to.

As I mentioned in my previous comment (with relevant links), because of the conflict between Prettier and Airbnb's style guide on parentheses-wrapped multiline expressions, anyone who follows the Airbnb style guide (both the code-quality and formatting rules) is not using Prettier (Prettier doesn't have the setting and ESLint has no plans to add auto fix for the conflict).

That's a massive developer base who would no doubt like to use Prettier but literally can't, as it currently stands. Keep in mind, these developers are using single quotes.

In other words, if the goal here is to figure out what current (biased) Prettier users are doing, then you'll likely see something pretty close to the current defaults. But surveying the developer community as a whole will yield very different results.

jabacchetta on 9 Nov 2019

Mh yea... it was late yesterday and I wanted to have some fun with GitHub's GraphQL ^^

I don't know if it's the right way to only look into repos
Like @nickmccurdy and @jabacchetta and others pointed out
it is not very representative and maybe there are repos that were to lazy to configure prettier and so on

Shinigami92 on 9 Nov 2019

@thorn0 time to close this issue, I think?

bakkot on 23 Mar 2020

Prettier: Prettier 2.0 (old)

This is NOT the current plan for Prettier v2.0. We’ve significantly scaled back our plans for what Prettier 2.0 will do, allowing us to get a less-controversial release out sooner: https://github.com/prettier/prettier/issues/6888

Easy?

CLI:

2691 - CLI defaults to `"**/*.{js,ts,...}"`.

2846 - Replace the "parser" option with "language".

For debate

838 - Consistently add quotes to object keys.

Outdated

Most helpful comment

All 184 comments

1139 - Put a space after the n in function () {}

838 - Consistently add quotes to object keys.

Summary:

2691 - CLI defaults to...

Related issues

Prettier: Prettier 2.0 (old)

This is NOT the current plan for Prettier v2.0. We’ve significantly scaled back our plans for what Prettier 2.0 will do, allowing us to get a less-controversial release out sooner: https://github.com/prettier/prettier/issues/6888

Easy?

CLI:

2691 - CLI defaults to "**/*.{js,ts,...}".

2846 - Replace the "parser" option with "language".

For debate

838 - Consistently add quotes to object keys.

Outdated

Most helpful comment

All 184 comments

1139 - Put a space after the n in function () {}

838 - Consistently add quotes to object keys.

Summary:

2691 - CLI defaults to...

Related issues

2691 - CLI defaults to `"**/*.{js,ts,...}"`.