Path aliases in create-t3-app code

[ochicf]

Is your feature request related to a problem? Please describe.
We decided that the scaffolded app will not have path aliases here: #85

But it was raised that maybe for the create-t3-app code would be worth having a new discussion, as this would only affect contributors and they were not the target of the decisions taken in the original issue.

Describe the solution you'd like
Define path aliases in create-t3-app so contributors have an easier and consistent way of importing code. In this issue we can propose/discuss what is the path aliases that we want to have, then decide and create a MR from it.

Describe alternatives you've considered
Leave imports as they are.

[ochicf]

My proposal for code in src folder:

• symbol: ~
  • (+) not confused with the @ of namespaced packages
  • (+) uses the already common pattern of describing "home" in unix systems
  • (-) not sure if it's a char commonly accessible in all keyboard layouts? (in the spanish layout it's easy to type)
• targets: ~/* to src/*. This would mean that ~/helpers point to src/helpers, ~/utils to src/utils, etc.
  • (+) behaves as a folder
  • (+) no need to set new aliases if new folders/files in src are created
  • (-) would allow to import some files that shouldn't be imported such as src/index.ts

---

I would like to raise an extra point aswell: in #116 (comment) I've defined a typescript submodule, and I would like to have path aliases there aswell. We should avoid clashes with the ones defined above so I would propose to use the ~template/* approach (where template would be the name of the sub-package, in case we add new ones).

• (+) uses same symbol
• (-) not fully consistent with how the ~ behaves for src as described above
• (-) we would have to define a new alias for each new sub-package (which I don't think it will happen that often though)
• (-) in comparison to ~* to src/*, we may have weird cases with the symbol ~ and leading vocals such as a and o where typing ~ and that vocal would yield ã and õ, having to type a space in the middle to prevent this.

---

Some examples with all of the above:

// importing from src
import { PKG_ROOT } from "~/consts.ts";
import { buildPkgInstallerMap } from "~/installers/index.ts";
import { getUserPkgManager } from "~/utils/getUserPkgManager.js";


// importing from a subpackage
import { BaseContextTransformOptions } from "~transform/addons/trpc/base-context.js";

[alonzuman]

looks awesome thats literally what i was about to open a PR for

[t3dotgg]

Path aliases make moving to monorepos quite painful and are generally very opinionated. I think we decided awhile back to not do this for those reasons

[nexxeln]

Path aliases make moving to monorepos quite painful and are generally very opinionated. I think we decided awhile back to not do this for those reasons

They're talking about path aliases in the CLI code, not the template.

[juliusmarminge]

Im down for including it in the cli code

[alonzuman]

Path aliases make moving to monorepos quite painful and are generally very opinionated. I think we decided awhile back to not do this for those reasons

I kind of feel like path aliases are the only way that allows the company I work for to actually move to a monorepo -

We had imports like ../../... x 8 (poor programming I know) and by refactoring to absolute imports, we could move stuff around without being afraid it will break stuff and then we could move to a monorepo when everything is organized, for example:

'src/components/FilePickers/Unsplash/components/UnsplashPicker' is now '/unsplash/components/...' and it imports from '/design-system' (previously ../../../design-system) and finally can be extracted (with turborepo/nx) to packages/unsplash etc'

[alonzuman]

Path aliases make moving to monorepos quite painful and are generally very opinionated. I think we decided awhile back to not do this for those reasons

I kind of feel like path aliases are the only way that allows the company I work for to actually move to a monorepo -

We had imports like ../../... x 8 (poor programming I know) and by refactoring to absolute imports, we could move stuff around without being afraid it will break stuff and then we could move to a monorepo when everything is organized, for example:

'src/components/FilePickers/Unsplash/components/UnsplashPicker' is now '/unsplash/components/...' and it imports from '/design-system' (previously ../../../design-system) and finally can be extracted (with turborepo/nx) to packages/unsplash etc'

Maybe it should actually be a cli option (but then the next question is what makes something a cli option? Why this and not that etc)

[ochicf]

Sorry if maybe I wasn't clear enough in OP, the intent of this issue is to add path aliases in the code that generates the project, not the code of the project being created.

So to clarify: path aliases resulting from this issue would only be noticeable by contributors of this project.

[abui-am]

Great idea, but should we refactor all of cli code using path alias after adding the config?
or should we leave it as it should be?

[juliusmarminge]

Great idea, but should we refactor all of cli code using path alias after adding the config?

or should we leave it as it should be?

Ideally refactor everything too