[Bug?]: Error using `~` alias from package

[oscartbeaumont]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

If you use the Typescript import alias ~ from within a package it resolves incorrectly throwing an error.

For context I am also using the vite-tsconfig-paths plugin which correctly handles this situation on a regular Vite app.

You can reproduce the behaviour by running this Solid Start app.

You will seeing the following error in the browser:

[plugin:vite:import-analysis] Failed to resolve import "~/demo" from "lib/src/index.ts". Does the file exist?
/Users/oscar/Desktop/solid-project/lib/src/index.ts:2:7
import "~/demo";

Expected behavior 🤔

No response

Steps to reproduce 🕹

Repository or Stackblitz

• pnpm i
• pnpm dev
• See error on http://localhost:3000

Context 🔦

I am fairly sure the fact that Solid Start defines a resolver for ~ which points to the app root is causing the code within the subpackages to try and resolve the alias relative to the root of the app and not the current package.

This can kinda be confirmed by enabling this pnpm patch which removes that resolver and noticing that the error goes away.

Your environment 🌎

No response

[ryansolid]

Hmm.. so it doesn't sound like there is a reasonable solution at the moment. Vite plugin I'm gathering doesn't work because we use 3 vite builds in Vinxi to create the separate module graph needed. Otherwise that would have been the solution here. Having alias at the app level is a SolidStart feature and libraries depending on this you'd hope not have this issue with their output types but if they do then it seems messy regardless.

[AlexErrant]

FWIW, Turborepo recommends multipackage repos to "Use Node.js subpath imports instead of TypeScript compiler paths". I've no experience with Node.js subpath imports, so cannot comment further.

[kattsushi]

any new on this ?

[brenelz]

reproduced on the v2 beta (plus the silent wrong-file case when paths collide); the vinxi-era blocker is gone and an importer-scoped resolver in solidStart() is now a viable fix.