filename literal string type

[jamiebuilds]

Suggestion

🔍 Search Terms

• import
• meta
• url
• __filename
• __dirname

✅ Viability Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Provide current filename (relative to current --project) as a type

tsconfig.json
path/to/file.ts

// path/to/file.ts
function assert(value: "path/to/file.ts") {}
declare var filename: __FILENAME_TYPE__
assert(filename)

Note: __FILENAME_TYPE__ is a placeholder for whatever makes most sense.

This should be separate from __filename (which is an absolute path that can change depending on the location of a typescript project) and import.meta.url which is a fully qualified URL and may also change at runtime.

📃 Motivating Example

An increasing number of web frameworks are using file system paths as a router with $parameters.tsx and such: Next, Gatsby, Remix, Nuxt, etc

/pages/
  index.ts     -> /
  /nested/
    index.ts   -> /nested
    $param.ts  -> /nested/:param

With the addition of `template literal ${types}` people are now parsing out parameters from runtime routers.

router.get("/path/to/:name", (req) => {
  let name: string = req.params.name // (no any)
})

If the current filename was accessible in typescript, you could strictly type path segments without repeating the path name

// path/to/$name.tsx
import type { Params } from "framework"

export default function renderPage(params: Params<__FILENAME_TYPE__>) {
  let name: string = req.params.name // (no any)
}

[DanielRosenwasser]

I don't exactly know whether this is possible because files can overlap across projects. That would mean you'd create a type that could differ across different language services, even if they have the same type-checking flags configured.

Another issue here would be the difference between what people have in mind between

• the current file's path
• the emitted file's path
• any module path that resolves to either of the above

[mb21]

I was looking for a solution to the same problem. It currently seems impossible to infer the name of route params in file-based or directory-based routers. Mentioning meta.import.dir, meta.import.file and meta.import.path here – which is what Bun and Deno use – so that this issue can be found easier. They also settled for emitting the current file's path *.ts, not the emitted file's path *.js.

To make this the same regardless of computer, we'd want the path relative to the nearest tsconfig.json. And it should be the same type regardless of OS (/ vs \). Given all that, for the current file /path/to/project/src/index.ts we would want the path: ['src', 'index.ts']

But yes, I have to admit that this is a tall order, especially given that there is not even a standard JS function in any runtime that returns the corresponding runtime value.