Comments (10)
I'm personally against using path aliases within a single application project. Typescript supports it for the sake of libraries, and Nest integrates with tsconfig-paths
to keep people from complaining to us that path aliases don't work, but I don't think we should be supporting this pattern by default. If you were to just run tsc
and node dist/main
, it actually could break how things run, and the reason isn't evident to a newcomer.
from nest.
that's even worse to me because, unlike Next.js, nestjs doesn't need to tell us on how our path aliases should look like. Perhaps we just need to make a recipe in the docs site on how to use path aliases
from nest.
A recipe would be a good fit, I think
from nest.
The goal is not to have it by default, instead, opt-in without the hassle of doing and breaking the project.
from nest.
By having it as an option, in my opinion, we would be encouraging bad development practices, which I don't believe fall inline with the desires of the framework. I'll let @kamilmysliwiec have the final say, but that's my two cents
from nest.
By having it as an option, in my opinion, we would be encouraging bad development practices, which I don't believe fall inline with the desires of the framework. I'll let @kamilmysliwiec have the final say, but that's my two cents
Why would this be a bad development practice?
See, when you create a new NestJS project today, on app.e2e-spec.ts we get the following import statement:
import { AppModule } from './../src/app.module'
With path alias, this would become something like:
import { AppModule } from '@/app.module'
Much cleaner.
from nest.
but now you're kinda mixing testing config with app config. But yeah, it's cleaner for sure
To me, ideally, we need a tsconfig file for test
dir and another for src
, which is not the case for the current version of the typescript starter
from nest.
Why would this be a bad development practice?
Again, Typescript allows for aliases for the sake of libraries. Typescript's golden rule is to not change the import statements during compilation (save for import to require for CJS). Nest makes this work by integrating tsconfig-paths
, but that's mainly because there were way too many "it doesn't work" issues where people didn't know that Typescript didn't actually behave this way. So if Typescript doesn't do this by default, I think we shouldn't encourage it either. Again, my two cents, and I'll leave the final decision to Kamil, but it's certainly something I think we should keep in mind.
Also, your first import statement has an extra ./
that could be removed. Not too much cleaner, but a bit
from nest.
but now you're kinda mixing testing config with app config. But yeah, it's cleaner for sure
To me, ideally, we need a tsconfig file for
test
dir and another forsrc
, which is not the case for the current version of the typescript starter
For the way NestJS organizes it's folders, maybe 2 aliases would be better, one for src and another for test. The tsconfig.json would become like:
{
"compilerOptions": {
// other options
"paths": {
"@/*": ["src/*"],
"#/*": ["test/*"],
}
}
}
As a consequence, a ts file created under test folder could have it's import statement like
import { getTestApp } from '#/util';
from nest.
This is a TypeScript compiler's feature. I don't see a reason why we should be duplicating docs and creating a recipe on something that Nest didn't introduce in the first place
#13294 (comment) couldn't agree more
from nest.
Related Issues (20)
- New project setup is failing
- Add a ParseNullPipe to the common library HOT 1
- Security Vulnerability on NestJS HOT 5
- double middleware execuation HOT 5
- Exclude Global Prefix + Middleware leads to wrong params HOT 2
- ESM support HOT 8
- @Req still undefinied with reflect-metadata@^0.2 HOT 3
- Is a good idea to make auto import when generate files using cli? HOT 1
- Allow readonly arrays as providers, imports, etc. HOT 3
- Validation fails in RPC context for MqttContext HOT 6
- Only the last APP_FILTER providers works HOT 4
- dependency injection does not work. HOT 3
- gRPC Streaming endpoints that throw errors crash the main process HOT 2
- Injectable instances can have references to Request objects and can hold it forewer in request scope
- Middleware consumer have a text error HOT 3
- Extra options are set only to default values when using `registerAsync` HOT 2
- Can we have a template resource for graphql + rest together? HOT 5
- Connection Error in Service during Startup HOT 2
- Wrong type (as in #12264) HOT 3
- Nest CLI generates the wrong package.json file HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nest.