Skip to content

Conversation

@pi0
Copy link
Member

@pi0 pi0 commented Nov 6, 2025

As many tools already infering options from tsconfig.json, nitro core can use it too.

Using lighweight tsconfck + cache.

TODO:

  • Load
  • Aliases
  • JSX options

@vercel
Copy link

vercel bot commented Nov 6, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
nitro.build Ready Ready Preview Comment Nov 7, 2025 10:42am

@drewbaker
Copy link

drewbaker commented Nov 6, 2025

@pi0 How does this relate to Node sub path imports defined in package.json? And the alias config in Nitro?

package.json:

    "imports": {
        "#server/*": "./server/*"
    }

nitro.config.ts

    alias: {
        "#server/*": resolve(__dirname, "./server/*"),
    },

And then the tsconfig.json:

        "paths": {
            "#server/*": [
                "./server/*"
            ]
        },

Do we need all of them? Can we use ~/ instead for all of them somehow? I thought Node sub-path needed to start with a # so seems maybe that is the best default to use instead of ~?

I've been trying for days to get Sidequest.js working with Nitro and having the import paths all work between Node and Nitro would just be so useful for that type of thing.

@pi0
Copy link
Member Author

pi0 commented Nov 7, 2025

@drewbaker subpath imports (by node convention) should start with # and should already work.

Tested on playground:

"imports": {
    "#server/*": "./*"
}

@pkg-pr-new
Copy link

pkg-pr-new bot commented Nov 7, 2025

Open in StackBlitz

npm i https://pkg.pr.new/nitrojs/nitro@3757

commit: 6b18e95

@drewbaker
Copy link

@drewbaker subpath imports (by node convention) should start with # and should already work.

Tested on playground:

"imports": {
    "#server/*": "./*"
}

Yeah they do work great, just seems like an overlap of the ~ convention, except ~ import's won't work in Node... So seemed to me that ideal use case would be that Nitro should just use #server (or maybe #nitro?) instead of ~/

@pi0
Copy link
Member Author

pi0 commented Nov 7, 2025

It is in the end choice of users nitro v3 is not having any defaults. I do also prefer subpath imports which are more standard than tsconfig pathh…

@drewbaker
Copy link

OK great, good to know. What do you use as the path? #server/*? #nitro/*? Just curious. I'll start using it instead of ~/ for all my imports now.

@MickL
Copy link
Contributor

MickL commented Nov 7, 2025

I would love to see ~/utils, ~/assets, etc. working. That is the convention of Nuxt and old Nitro so to me it makes sense to keep using it.

@pi0
Copy link
Member Author

pi0 commented Nov 7, 2025

What do you use as the path? #server/? #nitro/?

I think #server/* (if you prefer subpath) or ~/server (if prefer typescript aliases) might make best sense. All paths relative to one root.

But anyway nitro won't be opinionated on this. All up to projects.

@pi0
Copy link
Member Author

pi0 commented Nov 7, 2025

/cc @schiller-manuel (this works alongside vite-tsconfig-paths but also without it now)

@pi0 pi0 marked this pull request as ready for review November 7, 2025 10:30
@pi0 pi0 merged commit 121cb7e into main Nov 7, 2025
7 of 8 checks passed
@pi0 pi0 deleted the feat/tsconfig-aliases branch November 7, 2025 10:41
@MickL
Copy link
Contributor

MickL commented Nov 12, 2025

Hey @pi0 , I just checked this. Shouldnt it be "~/server/*": ["./server/*"], with a slash after ~, in the examples? That is how it was working in Nuxt:

import { useSomething } from '~/utils/use-something';

instead of:

import { useSomething } from '~utils/use-something';

Ofc this is up to the user, but from my experience official docs and examples always determine code conventions broadly used.

@pi0
Copy link
Member Author

pi0 commented Nov 12, 2025

In starters it is more generic even https://github.com/nitrojs/starter/blob/7e9adcc03658ba4dee99f6030daa699acb8755bf/tsconfig.json#L5

In example i just wanted to show interchangeable #server or ~server alias creation.

@MickL
Copy link
Contributor

MickL commented Nov 12, 2025

Perfect for the starter !! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants