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/faq/errors.md
+9-34Lines changed: 9 additions & 34 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,8 @@
1
-
###Common errors
1
+
## Common errors
2
2
3
3
During your development with NestJS, you may encounter various errors as you learn the framework.
4
4
5
-
####"Cannot resolve dependency" error
5
+
### "Cannot resolve dependency" error
6
6
7
7
Probably the most common error message is about Nest not being able to resolve dependencies of a provider. The error message usually looks something like this:
8
8
@@ -23,9 +23,9 @@ There are a few gotchas, that are common. One is putting a provider in an `impor
23
23
24
24
If you run across this error while developing, take a look at the module mentioned in the error message and look at its `providers`. For each provider in the `providers` array, make sure the module has access to all of the dependencies. Often times, `providers` are duplicated in a "Feature Module" and a "Root Module" which means Nest will try to instantiate the provider twice. More than likely, the module containing the `provider` being duplicated should be added in the "Root Module"'s `imports` array instead.
25
25
26
-
If the `unknown_token` above is the string `dependency`, you might have a circular file import. This is different from the [circular dependency](./errors.md#circular-dependency-error) below because instead of having providers depend on each other in their constructors, it just means that two files end up importing each other. A common case would be a module file declaring a token and importing a provider, and the provider import the token constant from the module file. If you are using barrel files, ensure that your barrel imports do not end up creating these circular imports as well.
26
+
If the `unknown_token` above is the string `dependency`, you might have a circular file import. This is different from the [circular dependency](#circular-dependency-error) below because instead of having providers depend on each other in their constructors, it just means that two files end up importing each other. A common case would be a module file declaring a token and importing a provider, and the provider import the token constant from the module file. If you are using barrel files, ensure that your barrel imports do not end up creating these circular imports as well.
27
27
28
-
#####Error on monorepos
28
+
#### Error on monorepos
29
29
30
30
If you are in a monorepo setup, you may face the same error as above but for core provider called `ModuleRef` as a `<unknown_token>`:
31
31
@@ -50,38 +50,13 @@ This likely happens when your project end up loading two Node modules of the pac
50
50
└── @nestjs/core
51
51
```
52
52
53
-
###### Fix for Yarn Workspaces
53
+
Solutions:
54
54
55
-
To circumvent that file structure in **Yarn** Workspaces, you can leverage on its [_nohoist_ feature](https://classic.yarnpkg.com/blog/2018/02/15/nohoist):
55
+
-**Yarn** Workspaces: use the [_nohoist_ feature](https://classic.yarnpkg.com/blog/2018/02/15/nohoist) to prevent hosting the package `@nestjs/core`.
56
56
57
-
```json
58
-
{
59
-
"workspaces": {
60
-
"packages": [],
61
-
"nohoist": [
62
-
"**/@nestjs/**"
63
-
]
64
-
}
65
-
}
66
-
```
67
-
68
-
Then, after `yarn install`, you'll get something like this:
69
-
70
-
```text
71
-
.
72
-
├── package.json
73
-
├── apps
74
-
│ └── api
75
-
│ └── node_modules
76
-
│ ├── @nestjs/core
77
-
│ └── @nestjs/bull
78
-
└── node_modules
79
-
└── (other packages)
80
-
```
81
-
82
-
#### "Circular dependency" error
57
+
### "Circular dependency" error
83
58
84
-
Occasionally you'll find it difficult to avoid [circular dependencies](/fundamentals/circular-dependency) in your application. You'll need to take some steps to help Nest resolve these. Errors that arise from circular dependencies look like this:
59
+
Occasionally you'll find it difficult to avoid [circular dependencies](https://docs.nestjs.com/fundamentals/circular-dependency) in your application. You'll need to take some steps to help Nest resolve these. Errors that arise from circular dependencies look like this:
85
60
86
61
```bash
87
62
Nest cannot create the <module> instance.
@@ -97,7 +72,7 @@ Scope [<module_import_chain>]
97
72
98
73
Circular dependencies can arise from both providers depending on each other, or typescript files depending on each other for constants, such as exporting constants from a module file and importing them in a service file. In the latter case, it is advised to create a separate file for your constants. In the former case, please follow the guide on circular dependencies and make sure that both the modules **and** the providers are marked with `forwardRef`.
99
74
100
-
####Debugging dependency errors
75
+
### Debugging dependency errors
101
76
102
77
Along with just manually verifying your dependencies are correct, as of Nest 8.1.0 you can set the `NEST_DEBUG` environment variable to a string that resolves as truthy, and get extra logging information while Nest is resolving all of the dependencies for the application.
0 commit comments