When tests/** are not included in the tsconfig, the TS language features in Vscode become inaccessible

Question

When tests/** are not included in the tsconfig, the TS language features in Vscode become inaccessible

I am looking to configure my TypeScript tests in such a way that they receive linting, code completion, and VSCode intellisense (TypeScript language features) when the test folder is placed next to the src folder. However, I want to ensure that my tests do not transpile when building my TypeScript project.

The structure of my TypeScript node project looks like this:

.    
├── server
│   │ 
│   │    
│   ├── src
│   │   │
│   │   └── app.ts
│   ├── test
│   │   │
│   │   └── app.test.ts
│   ├── node_modules/
│   ├── package-lock.json
│   ├── package.json
│   ├── tslint.json
│   └── tsconfig.json
├── front_end/
└── README.md

Here's an excerpt from my tsconfig:

{
  "compilerOptions": {
    "baseUrl": ".",
    "module": "commonjs",
    "moduleResolution": "node",
    "outDir": "dist",
    "sourceMap": true,
    "strict": true,
    "target": "ESNext",
    "paths": {
      "*": ["node_modules/*"]
    }
  },
  "include": ["src/**/*"]
}

When I access my test files in VSCode, the language feature does not recognize types and packages installed in node_modules. Interestingly, if I open VSCode only in the server folder (which is not the root based on my folder structure), the language features work properly 🧐.

My tests utilize ts-jest for execution, hence eliminating the need for tsc. Would it be recommended to extend a separate tsconfig.json specifically for tests 🤔?

Should I try tweaking some settings or consider submitting a bug report to https://github.com/microsoft/vscode/issues/new/choose.

typescript visual-studio-code jestjs ts-jest

Answer 1

Answer №1

There is an issue with Vscode when using a single root tsconfig file. If you have a test folder adjacent to the src folder, it will use the tsconfig (added in this specific pull request) but it may not work properly if the folder you open is one directory above it, such as having a server and client folder setup. You can follow the progress of the solution for this problem in this GitHub issue.

Furthermore, if you are looking to switch from tslint to eslint, you will need to add a tsconfig file to the test folder in order to exclude it from the main tsconfig. You can find detailed instructions on how to set up eslint with multiple tsconfig files in the provided link.

An easy workaround for these issues is to create two additional tsconfig files - one for the linter (tsconfig.eslint.json) and one specifically for tests inside the test folder (test/tsconfig.json). The content of the test tsconfig file should include the following:

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "noEmit": true
  },
  "include": ["./**/*"]
}

Although this solution may not be very elegant, at the moment it seems to be the best available option.

Answer 2

There is an issue with Vscode when using a single root tsconfig file. If you have a test folder adjacent to the src folder, it will use the tsconfig (added in this specific pull request) but it may not work properly if the folder you open is one directory above it, such as having a server and client folder setup. You can follow the progress of the solution for this problem in this GitHub issue.

Furthermore, if you are looking to switch from tslint to eslint, you will need to add a tsconfig file to the test folder in order to exclude it from the main tsconfig. You can find detailed instructions on how to set up eslint with multiple tsconfig files in the provided link.

An easy workaround for these issues is to create two additional tsconfig files - one for the linter (tsconfig.eslint.json) and one specifically for tests inside the test folder (test/tsconfig.json). The content of the test tsconfig file should include the following:

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "noEmit": true
  },
  "include": ["./**/*"]
}

Although this solution may not be very elegant, at the moment it seems to be the best available option.

Answer 3

Answer №2

Unfortunately, I am currently without my computer to verify this, but it seems that you simply need to insert the following code into your ts json file.

"exclude": [
        "node_modules",
        "**/*.test.ts"
    ]

Breakdown: Exclude ** all directories / * all TypeScript files containing .test in their names.

If you are not utilizing node then you may exclude the node_modules section. However, I have included it in my response for those who do use node and may copy the exclusion. By default, node_modules is already excluded, but additional modifiers can override that.

Best of luck with your implementation.

I hope this solution aligns with what you are seeking.

Answer 4

Unfortunately, I am currently without my computer to verify this, but it seems that you simply need to insert the following code into your ts json file.

"exclude": [
        "node_modules",
        "**/*.test.ts"
    ]

Breakdown: Exclude ** all directories / * all TypeScript files containing .test in their names.

If you are not utilizing node then you may exclude the node_modules section. However, I have included it in my response for those who do use node and may copy the exclusion. By default, node_modules is already excluded, but additional modifiers can override that.

Best of luck with your implementation.

I hope this solution aligns with what you are seeking.

Answer 5

Answer №3

A useful tip is to extend your tsconfig for a common, production, and development setup. Here's how we do it:

tsconfig.common.json - holds shared settings for both development and production environments.

tsconfig.json - the development version with tests included:

{
    "extends": "./tsconfig.common",
    "exclude": ["bin", "node_modules"]
}

tsconfig.prod.json - the production version without tests:

{
    "extends": "./tsconfig.common",
    "exclude": ["bin", "node_modules", "tests", "**/*.spec.ts"]
}

In our webpack.config, we follow a similar structure:

webpack.common.js - contains shared configurations for both environments

webpack.dev.js - utilizes the development tsconfig:

rules: [
        {
            test: /\.ts$/,
            exclude: [/bin/, /node_modules/],
            include: /ClientApp/,
            loader: 'ts-loader',
            options: {
                appendTsSuffixTo: [/\.vue$/],
                configFile: 'tsconfig.json'
            }
        }
    ]

webpack.prod.js - uses the production tsconfig:

rules: [
        {
            test: /\.ts$/,
            exclude: [/bin/, /node_modules/],
            include: /ClientApp/,
            loader: 'ts-loader',
            options: {
                appendTsSuffixTo: [/\.vue$/],
                configFile: 'tsconfig.prod.json'
            }
        }
    ]

Lastly, ensure the package.json file includes the following scripts:

scripts: {
    "dev": "webpack --config webpack.dev.js",
    "build": "webpack --config webpack.prod.js",
}

This approach should streamline your configuration process. Good luck!

Answer 6

A useful tip is to extend your tsconfig for a common, production, and development setup. Here's how we do it:

tsconfig.common.json - holds shared settings for both development and production environments.

tsconfig.json - the development version with tests included:

{
    "extends": "./tsconfig.common",
    "exclude": ["bin", "node_modules"]
}

tsconfig.prod.json - the production version without tests:

{
    "extends": "./tsconfig.common",
    "exclude": ["bin", "node_modules", "tests", "**/*.spec.ts"]
}

In our webpack.config, we follow a similar structure:

webpack.common.js - contains shared configurations for both environments

webpack.dev.js - utilizes the development tsconfig:

rules: [
        {
            test: /\.ts$/,
            exclude: [/bin/, /node_modules/],
            include: /ClientApp/,
            loader: 'ts-loader',
            options: {
                appendTsSuffixTo: [/\.vue$/],
                configFile: 'tsconfig.json'
            }
        }
    ]

webpack.prod.js - uses the production tsconfig:

rules: [
        {
            test: /\.ts$/,
            exclude: [/bin/, /node_modules/],
            include: /ClientApp/,
            loader: 'ts-loader',
            options: {
                appendTsSuffixTo: [/\.vue$/],
                configFile: 'tsconfig.prod.json'
            }
        }
    ]

Lastly, ensure the package.json file includes the following scripts:

scripts: {
    "dev": "webpack --config webpack.dev.js",
    "build": "webpack --config webpack.prod.js",
}

This approach should streamline your configuration process. Good luck!

When tests/** are not included in the tsconfig, the TS language features in Vscode become inaccessible

Answer №1

Answer №2

Answer №3

Similar questions

Prevent the Icon in Material UI from simultaneously changing

What is the correct method for storing a response in an array variable in Angular?

Exploring through objects extensively and expanding all their values within Angular

An easy method to define argument types for every function type in TypeScript

Guide on how to create a custom response using class-validator in NestJS

Retrieving information from a JSON object in Angular using a specific key

Combining Rollup, Typescript, and converting images to base64 during the loading process

Can ngFor be utilized within select elements in Angular?

What is the best way to retrieve a specific field from the observable data stream?

Utilizing images in a compiler run with the option of `allowJS:true` is key

Validating patterns in Angular without using a form

Attempting to invoke a TypeScript firebase function

Is there a way to make Firebase Cloud Functions utilize ESLint?

Problem with organizing data by dates

Angular 14 debug error: Incorrect base path setting

What makes TypeScript code run successfully using `node` instead of `ts-node` by mistake?

Context failing to refresh value upon route changes

Putting DashJS to the test with Jest and Enzyme

Setting up a Typescript project with a shared package configuration

Retrieving the Object value in Primeng p-dropdown when there is a change in selection