tsdx: VS Code does not automatically 'play nicely' with tsdx

BEWARE – you might be over complicating/overthinking things with your vscode setup!

I certainly did. I wasted MANY hours messing around with config files, plugins, npm packages, etc., before coming to realize that everything I wanted was pretty much provided by tsdx from the start. Before I go on, let me make clear the two goals that I wanted to achieve with my tsdx-vscode setup:

1. Get vscode to format (on save) all my code files based upon rules given in (ideally) one config file
2. Get husky to format my code based upon those same rules whenever I make a git commit (so that others working on the same code will end up with the same formatting regardless of their editing environment)

That’s it. I don’t need super-fancy configuration, I just want the ability to set basic things like single vs double quotes, tab size, etc. I also don’t mind being subject to “opinionated” rules sets, I mainly want consistency across my code base.

With that said, I eventually realized that tsdx (very nearly) gives me those two goals right out of the box via the “prettier” section in package.json, which looks like this:

{
  "prettier": {
    "printWidth": 80,
    "semi": true,
    "singleQuote": true,
    "trailingComma": "es5",
    "tabWidth": 2,
    "htmlWhitespaceSensitivity": "ignore"
  },
}

Note: I added the last two rules here.

In order to fulfill the first goal above, all you need is to do is the following:

• Install the vscode-prettier extension
• Make this extension your formatter in your settings.json file ("editor.defaultFormatter": "esbenp.prettier-vscode")

In order to fulfill the second goal, you just need to make the linting script called by husky “fix” your code by adding “–fix” within package.json:

  ...,
  "husky": {
    "hooks": {
      "pre-commit": "tsdx lint --fix"
    }
  },
  ...

And, voila, my two goals are met. If I now change e.g. “tabWidth”: 3 in my prettier block, then my files will readjust automatically upon formatOnSave, etc.

tl;dr

The reason I wasted so much time previously is because in my hasty read of the tsdx readme I inferred that in order to tweak your formatting rules you needed to create an eslint config file and then make that the single source of truth for your formatting rules. However, I was unable to get vscode to recognize such an eslint config file as the source of truth for my formatting rules (despite, as I said, many hours of trying different combinations of extensions, plugins, packages and configurations). Once I realized that you don’t need to use this eslint config file to set rules (i.e. all I needed was already there in the “prettier” block in package.json), I was able to strip away all the excess extensions, plugins, packages and was very pleased to end up with something so lean as, essentially, what tsdx gave me out of the box.

In summary: to avoid the sort of rabbit holes I went down, I would suggest making the following alteration to the tsdx readme (my suggested edits in bold):

Runs Eslint with Prettier on .ts and .tsx files according to rules given in the “prettier” block in package.json. You can get VSCode to format your code using those rules by installing the vscode-prettier extension and adding "editor.defaultFormatter": "esbenp.prettier-vscode" to your settings.json. If you want to customize eslint you can add an eslint block to your package.json, or you can run yarn lint --write-file and edit the generated .eslintrc.js file. However, it is more challenging to configure VSCode to use both the prettier block and an eslint configuration to format your code consistently.

This is broken for all ESLint extensions, not just for VSCode, as the config is missing. The solution is to do what create-react-app does and generate an ESLint config by default (as with --write-file). The tsdx lint command would still be useful as it uses some CLI flags that aren’t present in ESLint configs).

I resolved this by using yarn lint --write-file, but I’m surprised that this needs manual fixing; all it would take is something like "extends": "tsdx" in package.json.

Here’s eslint-config-react-app for reference. CRA uses a monorepo and multiple packages, but an alternative that allows keeping one package would be local paths, so something like this in package.json:

"dependencies": {
  "eslint-config-tsdx": "file:./node_modules/tsdx/eslint-config"
},
…
"eslintConfig": {
  "extends": "tsdx"
}

I’ve implemented something similar to (and inspired by) tsdx at work and faced this as well. ESLint plugin only works if it’s able to find a config - file or property on package.json.

My solution was to create an ESLint config package hiding the “magic” and just run ESLint through my CLI - which is going to read the config file. My CLI handles creating the file if it’s not there, support flags from CLIEngine, etc.

But I don’t know if tsdx maintainers would like to follow this route as they would have two packages to maintain instead of just one, so running tsdx lint --write-file could be the recommended approach.

/cc @jaredpalmer @sw-yx