You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/cli/workspaces.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ Nest has two modes for organizing code:
5
5
-**standard mode**: useful for building individual project-focused applications that have their own dependencies and settings, and don't need to optimize for sharing modules, or optimizing complex builds. This is the default mode.
6
6
-**monorepo mode**: this mode treats code artifacts as part of a lightweight **monorepo**, and may be more appropriate for teams of developers and/or multi-project environments. It automates parts of the build process to make it easy to create and compose modular components, promotes code re-use, makes integration testing easier, makes it easy to share project-wide artifacts like `eslint` rules and other configuration policies, and is easier to use than alternatives like github submodules. Monorepo mode employs the concept of a **workspace**, represented in the `nest-cli.json` file, to coordinate the relationship between the components of the monorepo.
7
7
8
-
It's important to note that virtually all of Nest's features are independent of your code organization mode. The **only**affect of this choice is how your projects are composed and how build artifacts are generated. All other functionality, from the CLI to core modules to add-on modules work the same in either mode.
8
+
It's important to note that virtually all of Nest's features are independent of your code organization mode. The **only**effect of this choice is how your projects are composed and how build artifacts are generated. All other functionality, from the CLI to core modules to add-on modules work the same in either mode.
9
9
10
10
Also, you can easily switch from **standard mode** to **monorepo mode** at any time, so you can delay this decision until the benefits of one or the other approach become more clear.
[Vitest](https://vitest.dev/) is a fast and lightweight test runner designed to work with Vite. It provides a modern, fast, and easy-to-use testing solution that can be integrated with NestJS projects.
102
+
103
+
#### Installation
104
+
105
+
To get started, first install the required packages:
106
+
107
+
```bash
108
+
$ npm i --save-dev vitest unplugin-swc @swc/core @vitest/coverage-c8
109
+
```
110
+
111
+
#### Configuration
112
+
113
+
Create a `vitest.config.ts` file in the root directory of your application with the following content:
114
+
115
+
```ts
116
+
importswcfrom'unplugin-swc';
117
+
import { defineConfig } from'vitest/config';
118
+
119
+
exportdefaultdefineConfig({
120
+
test: {
121
+
globals: true,
122
+
root: './',
123
+
},
124
+
plugins: [swc.vite()], // This is required to build the test files with SWC
125
+
});
126
+
```
127
+
128
+
This configuration file sets up the Vitest environment, root directory, and SWC plugin. You should also create a separate configuration
129
+
file for e2e tests, with an additional `include` field that specifies the test path regex:
130
+
131
+
```ts
132
+
importswcfrom'unplugin-swc';
133
+
import { defineConfig } from'vitest/config';
134
+
135
+
exportdefaultdefineConfig({
136
+
test: {
137
+
include: ['**/*.e2e-spec.ts'],
138
+
globals: true,
139
+
root: './',
140
+
},
141
+
plugins: [swc.vite()],
142
+
});
143
+
```
144
+
145
+
Additionally, you can set the `alias` options to support TypeScript paths in your tests:
146
+
147
+
```ts
148
+
importswcfrom'unplugin-swc';
149
+
import { defineConfig } from'vitest/config';
150
+
151
+
exportdefaultdefineConfig({
152
+
test: {
153
+
include: ['**/*.e2e-spec.ts'],
154
+
globals: true,
155
+
alias: {
156
+
'@src': './src',
157
+
'@test': './test',
158
+
},
159
+
root: './',
160
+
},
161
+
resolve: {
162
+
alias: {
163
+
'@src': './src',
164
+
'@test': './test',
165
+
},
166
+
},
167
+
plugins: [swc.vite()],
168
+
});
169
+
```
170
+
171
+
#### Update imports in E2E tests
172
+
173
+
Change any E2E test imports using `import * as request from 'supertest'` to `import request from 'supertest'`. This is necessary because Vitest, when bundled with Vite, expects a default import for supertest. Using a namespace import may cause issues in this specific setup.
174
+
175
+
Lastly, update the test scripts in your package.json file to the following:
"test:e2e": "vitest run --config ./vitest.config.e2e.ts"
185
+
}
186
+
}
187
+
```
188
+
189
+
These scripts configure Vitest for running tests, watching for changes, generating code coverage reports, and debugging. The test:e2e script is specifically for running E2E tests with a custom configuration file.
190
+
191
+
With this setup, you can now enjoy the benefits of using Vitest in your NestJS project, including faster test execution and a more modern testing experience.
192
+
193
+
> info **Hint** You can check out a working example in this [repository](https://github.com/TrilonIO/nest-vitest)
Copy file name to clipboardExpand all lines: content/security/helmet.md
+15Lines changed: 15 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,6 +20,21 @@ import helmet from 'helmet';
20
20
app.use(helmet());
21
21
```
22
22
23
+
> warning **Warning** When using `helmet`, `@apollo/server` (4.x), and the [Apollo Sandbox](https://docs.nestjs.com/graphql/quick-start#apollo-sandbox), there may be a problem with [CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) on the Apollo Sandbox. To solve this issue configure the CSP as shown below:
0 commit comments