If it must convert tabs to spaces, it suggest it should also do that within (JSDoc style) comments which now look like this:

  /**
	 * INDENTED WITH TABS (probably because comments are simply passed through)
	 * @param {String} key
	 * @param {function} base
	 * @returns {function}
	 */
  function getter(key, base) {
    return function() {
      console.log(key);
      return base.apply(this);
    };
  }

💁‍♂️ To minimize the amount of configuration related to supporting tabs, perhaps the relevant properties could be reduced to one setting editorconfig that points to an external file called .editorconfig as detailed on http://editorconfig.org/. This has bonus advantages:

Most code editors can be rigged with a plugin that automatically configures editors settings to conform (eg. to use spaces instead of tabs and set the tab-width to 2 and so on) so that anyone on the team will automatically adopt the settings.
The .editorconfig file can be placed in the root of a GitHub project to control the tab-width that users will see when they browse the repository. The browsers default width is 8 and this probably explains why many developers prefer spaces to tabs, but with this trick you can reduce it down to 4 or whatever you prefer.

In other words, your code editor and your GitHub repo and your Prettier command line tool would all consume the same settings with regards to tabs (or spaces), tab-widths and potentially also newlines.

Uh oh!

Support tabs for indentation #34

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions