Add path alias to nest new

[GustavoOS]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

I have an issue when I try to setup path alias, sometimes causing basic modules not to be found

Describe the solution you'd like

Adding a possibility to configure path alias in the CLI, similar to create-next-app

Teachability, documentation, adoption, migration strategy

When creating a new project, ask for the possibility to use import alias.

What is the motivation / use case for changing the behavior?

Avoid using long relative paths on import statements.

[jmcdo29]

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.

[GustavoOS]

The goal is not to have it by default, instead, opt-in without the hassle of doing and breaking the project.

[jmcdo29]

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

[GustavoOS]

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.

[micalevisk]

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

[jmcdo29]

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

[GustavoOS]

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

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';

[micalevisk]

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

[GustavoOS]

A recipe would be a good fit, I think

[kamilmysliwiec]

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