Great tutorial, Rubin! I've followed everything here, but I'm now running into an issue where Nest cannot resolve the dependencies if I import a class that is within the same directory using the tsconfig path alias. I opened up an issue with Nest, but I wonder if there's just something I'm not doing right. Issue here:
NOTE: This is not a duplicate of #986 as I am already using tsconfig-paths-bootstrap.js.
Current behavior
I've set a few different paths in tsconfig.json to make importing of controllers, entities, services, etc. easier to deal with. Relevant portion of tsconfig.json:
I've also created barrel files (index.ts) within the src/controllers/, src/entity/, and src/services/ directories that re-exports all of the classes that I need from within those directories.
Everything works as expected when importing a service from a file that is within my controllers directory. Example:
Things do NOT work when importing a service from another service file that is within the same directory. Example
// src/services/comment.service.ts// This does NOT workimport { StoryService, UserService } from'@hello/services';
// StoryService, UserService, and CommentService are in the src/services directory
@Injectable()
exportclassCommentService {...}
The error that I get when doing the above is:
Error: Nest can't resolve dependencies of the CommentService (?, +). Please make sure that the argument at index [0] is available in the AppModule context.
Expected behavior
I expect dependencies to resolve using a path defined in tsconfig.json, even if they're being imported from within the same directory.
Possible Solution
My current workaround is to import the files using relative paths:
// src/services/comment.service.ts// This does workimport { StoryService } from'./story.service';
import { UserService } from'./user.service';
// I'd prefer to do this:// import { StoryService, UserService } from '@hello/services';
@Injectable()
exportclassCommentService {...}
Its possibly an module import problem. Make sure to import the corresponding modules if you are using the services. Do check if you are missing an import
Also I would recommend to skip barrel if you are using path aliases because they do kind of the same thing. Also You could achieve a folderwise import with dir/* so there is no point in using it with path
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great tutorial, Rubin! I've followed everything here, but I'm now running into an issue where Nest cannot resolve the dependencies if I import a class that is within the same directory using the tsconfig path alias. I opened up an issue with Nest, but I wonder if there's just something I'm not doing right. Issue here:
Nest dependency resolution issue with tsconfig paths and same directory imports #2897
Bug Report
NOTE: This is not a duplicate of #986 as I am already using tsconfig-paths-bootstrap.js.
Current behavior
I've set a few different paths in tsconfig.json to make importing of controllers, entities, services, etc. easier to deal with. Relevant portion of tsconfig.json:
I've also created barrel files (index.ts) within the src/controllers/, src/entity/, and src/services/ directories that re-exports all of the classes that I need from within those directories.
Everything works as expected when importing a service from a file that is within my controllers directory. Example:
Things do NOT work when importing a service from another service file that is within the same directory. Example
The error that I get when doing the above is:
Expected behavior
I expect dependencies to resolve using a path defined in tsconfig.json, even if they're being imported from within the same directory.
Possible Solution
My current workaround is to import the files using relative paths:
Environment
Its possibly an module import problem. Make sure to import the corresponding modules if you are using the services. Do check if you are missing an import
Also I would recommend to skip barrel if you are using path aliases because they do kind of the same thing. Also You could achieve a folderwise import with dir/* so there is no point in using it with path