baseUrl and paths in tsconfig.json compatibility

[dkaerit]

Hi, this issue comes for the reason of a limitation which I found when creating my projects in deno. I usually like to create a folder where I incorporate all the routes to third party modules and from there I export everything to include it from those files

project
├─deno_deps
│  ├─djwt.ts
│  ├─mongo.ts
│  └─oak.ts
├─src
│  ├─app.ts
...  ...

ej: oak.ts

export { oakCors } from "https://deno.land/x/cors@v1.2.1/mod.ts";
export { Application, Router } from "https://deno.land/x/oak@v6.5.0/mod.ts";
export { getQuery } from "https://deno.land/x/oak@v6.5.0/helpers.ts";
export type { RouterContext, Context, RouteParams } from "https://deno.land/x/oak@v6.5.0/mod.ts";

And I think that I am not the only one who does this, and that in a certain way it is a good practice to be able to visualize in the same point all the modules on which the project depends

However, this causes that, if I want to import what I have in the folder, there are relative paths in the project which will mess up readability a bit

import { RouterContext } from "../../../_dependencies/oak.ts";
import { Query } from "../../../database/queries/mongo.queries.ts";
import { UserCollection } from "../models/user.model.ts"
import { JwtHelper } from "../../helpers/jwt.helper.ts";

For this reason, I consider that if it does include the possibility of establishing the baseUrl, and even the paths, in the tsconfig, it would greatly improve this aspect. Something that the typescript cli already brings with it.

"baseUrl": "src", 
...
"paths": {
    "@deps/*": ["deno_deps/*"],
    ...
},

[kitsonk]

Those options only inform the TypeScript type checker of the location of code at runtime. Because Deno manages the location of all code at runtime, these options would only make type checking or runtime code break.

Deno uses the web standard import maps to relocate code both at type check and runtime.

[AlphaMoonbaseBerlin]

But is there any specific reason to not resolve the paths during runtime?
I have not a lot of knowledge about the inner workings of deno here, but there must be some part that either compiles the TS code before running it (why not do it at this step?) or intreprets TS during runtime (suppose not.)

It is just a small thing but would make the live much easier as this huge collections of ../../ are def a source of error.
At least some way of creating an alias for a paths would be incredible.

[bartlomieju]

You should use import maps for this purpose

[bburns]

Just a small example -

in deno.json:

{
  "imports": {
    "@/": "./src/",
    ...
  },
}

then can do this anywhere -

import logger from '@/logger.ts'

[cj-1010-1414]

This is the answer. Just put imports outside compilerOptions.

[thoroc]

This just isn't my experience.

this is the error I am getting:

Relative import path "@cli/commands/greet.ts" not prefixed with / or ./ or ../deno(import-prefix-missing)

from this source code src/cli/index.ts:

import { Command } from "npm:commander";
import GreetCommand from "@cli/commands/greet.ts"; // <-- this isn't working
// import GreetCommand from "./src/cli/commands/greet.ts"; // <-- this is working

and this deno.json:

  "imports": {
    "@cli/": "./src/cli/",
    "commander": "npm:commander@^12.1.0",
    ...
  }

[petamoriken]

Just feedback, as it is very hard to migrate a Node.js project that uses baseUrl and paths in tsconfig.json to Deno, I felt that a tool to rewrite the paths in the import statement would be quite useful.

[allanpaiste]

Bumped into this as well and would also advise this to be solved as you'd just be winning over users from Node+TS when you solve this.

Having path aliases supported perhaps with a flag that is similar to unstable-sloppy-imports perhaps would be a good mid-way to allow the wide majority of projects that still run on Node to have smooth transition over to Deno which would only benefit the growing popularity of the latter.

I've noticed that Deno has already taken the route where one can get dependencies in place just based on package.json -- It's not a stretch then to go and be able to read paths config (at least simpler setups) from tsconfig.json

In short, perhaps this strategy will benefit Deno the most:

1. FIRST: Win over majority of the projects that are on Node+TS
2. THEN: Dictate how they are not doing things "the standard way"