VS Code does not automatically 'play nicely' with tsdx

[Vinno97]

Current Behavior

VS Code does not detect or use Eslint and Prettier in the workspace (out of the box).

Expected behavior

The first paragraph of the README seems to suggest VSCode will automatically work nicely with TSDX's environment. Leading me to believe it was plug-and-play.

Suggested solution(s)

Maybe create an (opinionated) settings file in the .vscode folder of the workspace? Or at least dedicate a section in the README to the required configurations in VS Code.

Additional context

This "bug" might be out of the intended scope of the project, but the README led me to believe it would work this way.

Your environment

Software	Version(s)
TSDX	0.11.0
TypeScript	3.7.2
Browser	-
npm/Yarn	6.13.0
Node	v12.13.0
Operating System	Linux 4.19.85-1-MANJARO x86_64

[rahsheen]

What changes did you need to make for this to work? I believe personally I just had to add the below to settings. Maybe this could be added to the README, but not sure if other steps are needed.

    "[typescriptreact]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[typescript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },

[Vinno97]

That does help to enable Prettier, but I mostly want to get ESLint to work (which also enables Prettier). And I haven't been able to get that to work.

In another project, without TSDX, I use:

{
    "eslint.autoFixOnSave": true,
    "eslint.validate": [
        "javascript",
        "javascriptreact",
        {
            "language": "html",
            "autoFix": true
        },
        {
            "autoFix": true,
            "language": "typescript"
        },
    ]
}

But that does not work here, since ESlint cannot find any configuration file (nor have I been able to find it manually):

No ESLint configuration (e.g .eslintrc) found for file: <workspace/file>
File will not be validated. Consider running 'eslint --init' in the workspace folder <workspace>
Alternatively you can disable ESLint by executing the 'Disable ESLint' command.

Am I missing something that should be obvious?

[swyxio]

docs welcome for this for sure

[Vinno97]

In the meantime. Can anyone tell me how I could get the ESLint configurations? I'd like to have an .eslintrc(.js) file, so I am able to use ESLint without the tsdx wrapper (so I can thus use VS Code and other tooling with ESLint).

[arvigeus]

@Vinno97 It's in the docs: https://github.com/jaredpalmer/tsdx#npm-run-lint-or-yarn-lint
yarn lint --write-file

[Vinno97]

Oh my apologies, I must have missed that. Thanks.

[slikts]

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.

[nickserv]

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).

[slikts]

CRA just adds extends to package.json; it doesn't output the config. This is what it does:

  "eslintConfig": {
    "extends": "react-app"
  },

[nickserv]

That is also an ESLint config.

[slikts]

I mean that if you use tsdx lint --write-file, it outputs the actual config, and using it loses the link to tsdx.

[nickserv]

I don't think that's going to be an issue as unlike CRA, tsdx allows overriding the config by default. It's also a fairly simple config with only three extends and a rule config (workaround for making React optional).

[slikts]

I'm not following; the issue is that --write-file is akin to "ejecting" in CRA, making the config unmanaged. CRA still allows customizing the ESLint config while keeping it managed; like so, for example:

  "eslintConfig": {
    "extends": "react-app",
    "rules": {
      "@typescript-eslint/no-unused-vars": "off"
    }
  },

The way tsdx currently works is a straightforward oversight.

[arthurdenner]

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

[slikts]

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"
}

[nickserv]

Yarn 2 is already stable and doesn't support node_modules by default, that would break without us specifically supporting resolve/pnpify. We could theoretically ship a separate package but I'm not sure that's worth the effort considering how simple the current config is.

I want to see how far I can get with always writing in the config but merging in older configs for back compatibility.

[MagnusBrzenk]

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.

[agilgur5]

Not sure what the exact issues you faced with using eslintrc are, but there is #514 which I've experienced first-hand. #634 has been my proposal to resolve these types of things so that there's actually sources of truth for all of these configs that aren't wired into TSDX internals in difficult to untangle ways.