Wasp•6d ago

Custom Aliases don't work after migrating from 0.15 to 0.16

I recently upgraded to Wasp v0.16 because I wanted to take advantage of the custom aliases. I installed shadcn using this guide, and got it working after swapping out the import paths and such as suggested. The problem is every time I add a new shadcn component the paths get written incorrectly and I have to go fix it. So I tried switching back to using aliases and Wasp just fails to compile with errors like Cannot find module '@/lib/utils' or its corresponding type declarations. The aliases are recognized by VSCode without any problems so I'm not sure why wasp is failing on this. Below are my settings main.wasp

app OpenSaaS {
  wasp: {
    version: "^0.16.0"
  },
...

app OpenSaaS {
  wasp: {
    version: "^0.16.0"
  },
...

tsconfig.json

{
  "compilerOptions": {
    "module": "esnext",
    "target": "esnext",
    "moduleResolution": "bundler",
    "jsx": "preserve",
    "strict": true,
    "esModuleInterop": true,
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "typeRoots": [
      "node_modules/@testing-library",
      "node_modules/@types"
    ],    
    "composite": true,
    "skipLibCheck": true,
    "outDir": ".wasp/out/user",
    "rootDir": "../", //allow importing of shared dir
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    }
  },
  "include": [
    "src"
  ],
}

{
  "compilerOptions": {
    "module": "esnext",
    "target": "esnext",
    "moduleResolution": "bundler",
    "jsx": "preserve",
    "strict": true,
    "esModuleInterop": true,
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "typeRoots": [
      "node_modules/@testing-library",
      "node_modules/@types"
    ],    
    "composite": true,
    "skipLibCheck": true,
    "outDir": ".wasp/out/user",
    "rootDir": "../", //allow importing of shared dir
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    }
  },
  "include": [
    "src"
  ],
}

components.json

{
  "$schema": "https://ui.shadcn.com/schema.json",
  "style": "default",
  "rsc": false,
  "tsx": true,
  "tailwind": {
    "config": "tailwind.config.cjs",
    "css": "index.css",
    "baseColor": "gray",
    "cssVariables": true,
    "prefix": ""
  },
  "aliases": {
    "components": "@/components",
    "utils": "@/lib/utils",
    "ui": "@/components/ui",
    "lib": "@/lib",
    "hooks": "@/hooks"
  },
  "iconLibrary": "lucide"
}

{
  "$schema": "https://ui.shadcn.com/schema.json",
  "style": "default",
  "rsc": false,
  "tsx": true,
  "tailwind": {
    "config": "tailwind.config.cjs",
    "css": "index.css",
    "baseColor": "gray",
    "cssVariables": true,
    "prefix": ""
  },
  "aliases": {
    "components": "@/components",
    "utils": "@/lib/utils",
    "ui": "@/components/ui",
    "lib": "@/lib",
    "hooks": "@/hooks"
  },
  "iconLibrary": "lucide"
}

Gist

Using ShadCN with Wasp 0.12+

Using ShadCN with Wasp 0.12+. GitHub Gist: instantly share code, notes, and snippets.

13 Replies

kapa.ai•6d ago

Hi @vance_solar. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Based on the information provided in the knowledge sources and your question, it seems you're encountering issues with custom aliases after migrating from Wasp v0.15 to v0.16. While the knowledge sources don't provide a direct solution to your specific problem, I can offer some insights and suggestions based on related information. 1. Recent changes in Wasp: According to Github Issue #1415, Wasp 0.12.0 introduced changes that removed the client and server separation. This might have affected how imports and aliases work in newer versions. 2. Potential solution for shadcn/ui: The gist you mentioned for installing shadcn/ui with Wasp is referenced in Discord support thread. This suggests that the method should work, but you might need to ensure all steps are followed correctly. 3. Import alias considerations: There was a discussion about using import aliases in Wasp, as mentioned in Github Issue #1011. However, this feature might not be fully implemented or might work differently than expected in the current version. 4. Troubleshooting steps: - Ensure you've run wasp start after upgrading, as mentioned in Discord support thread. This compiles the SDK and should make the wasp/* packages available. - If issues persist, try running wasp clean followed by wasp start to reinstall everything, as suggested in the same Discord thread. 5. Vite configuration: In a Discord support thread, there's mention of adding a vite.config.ts file to configure aliases. You might want to try this approach if it's not conflicting with your current setup. Given that your specific issue with custom aliases in Wasp 0.16 is not directly addressed in the provided knowledge sources, it might be a new or undocumented problem. If the above suggestions don't resolve your issue, you may need to reach out to the Wasp community or developers for more specific assistance. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @vance_solar, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

vance_solarOP•6d ago

I think I need human help I tried creating a brand new wasp v0.16 saas project and still get the above error

Vinny (@Wasp)•5d ago

@miho or @wardbox perhaps can be of help here.

vance_solarOP•4d ago

Thanks @Vinny (@Wasp) , hoping to get their input

MEE6•4d ago

Wohooo @vance_solar, you just became a Waspeteer level 2!

Filip•4d ago

Hey @vance_solar Unfortunately, 0.16.0 still doesn't work with Path aliases. We thought we got them working, but it turn out it's a larger can of worms than we expected. The reason it works in your IDE is because TypeScript recognizes it. The problem lies with other pieces of tooling (rollup, Vite, etc.) that don't still don't know about them. I've tried to get it working but hit a wall. We still hope to have them out soon, you can follow this issue for details: https://github.com/wasp-lang/wasp/issues/2518 Thanks for tolerating this btw! I know how annoying it is to work without aliases

vance_solarOP•3d ago

Thanks for the update @sodic - any ETA on when you think this will be supported? To add another data point, not having custom aliases is also preventing me from using shared components/types from outside the app folder. For some extra context, I needed SSR for a portion of my project so decided to include a NextJS app inside my Wasp repo. I needed access to some of the common types defined in my Wasp project so I moved them to a shared folder at the same level as “app”. My Next app is able to access this code with custom aliases but my Wasp app cannot, so for now I’m duplicating the common code in two places which is less than ideal.

Filip•3d ago

any ETA on when you think this will be supported?

We'll be doing some planning in the next week or two, so I'll get back to you as soon as we decide. But thanks for the feedback, this will definitely help prioritize it. I've added this message to my "folluw up" list. So, rest assured, I will update you as soon as I know more. As for the other question, I don't think the lack of aliases is causing that. You should still able to import them using full relative paths, but then I don't think that would work with Wasp (I'm 70% sure you can't import stuff from outside src). That said, I think I can solve this problem for you, can I just ask you share how your folder structure looks like? The tree command can be useful here, in case don't know about it 🙂

genyus•3d ago

I was actually about to post a question relating to this (external components) today myself. I have Wasp as one component in a monorepo (managed with Turborepo and pnpm) and I’ve now had to start creating shared components to use across Wasp and the browser extension. Because Wasp relies on npm and npm doesn’t support workspaces, I can’t use the same references as I do throughout the rest of the project. I tried adding the new shared package using a relative path, which works fine in the IDE, but then it falls over at runtime with a Vite error. I’ll share my setup once I’m back at my desk. I was able to fix it by adding an alias for the shared package in vite.config.ts:

import { resolve } from 'node:path';
import { defineConfig } from 'vite';

export default defineConfig({
  // snip
  resolve: {
    alias: {
      '@shared/documents': resolve(__dirname, '../../../apps/_/documents/dist/index.js'),
    },
  },
})

import { resolve } from 'node:path';
import { defineConfig } from 'vite';

export default defineConfig({
  // snip
  resolve: {
    alias: {
      '@shared/documents': resolve(__dirname, '../../../apps/_/documents/dist/index.js'),
    },
  },
})

Filip•3d ago

Hey @genyus, this looks like it's going to break when you move your files. Just a heads up if you didn't know. Another heads up, it's going to work only for client files But nice trick, @vance_solar you might find it useful

genyus•3d ago

this looks like it's going to break when you move your files.

Yup, I know it’s pretty brittle, but it’ll fail fast if I need to reorganise the project

it's going to work only for client files

Also fine in this scenario, as the shared package exclusively contains client-side code. I'd still like to hear the potential solution you mentioned, though? My project structure is follows:

apps/
├── _/
│   └── documents/ <= The shared components package
├── extensions/
│   └── chrome/
│   └── safari/
├── web/
    ├── app/ <= Wasp
    ├── blog/
    ├── docs/
    └── e2e-tests/

apps/
├── _/
│   └── documents/ <= The shared components package
├── extensions/
│   └── chrome/
│   └── safari/
├── web/
    ├── app/ <= Wasp
    ├── blog/
    ├── docs/
    └── e2e-tests/

Filip•3d ago

Well, one idea is putting your documents under web/app/src. That way, Wasp will always be able to access it with relative imports, and Next can use aliases that point to outside its project (since it supports that). Another idea is using hardlinks or symbolic links, but this is always hacky to get working depending on the OS (and version control), but I could probably help you out. @genyus I'm not sure whether this is your setup as well, I'm basing my suggestion on what @vance_solar wrote. @genyus For your setup, I think your solution is probably best

genyus•3d ago

Ah, I see. So technically, it's already using symbolic links to bring the external package into Wasp's node_modules (which is what it also does for wasp and wasp-config, AFAIK?). I'm not using Next, but I suppose I could just convert the existing feature directory into a standalone component that can get referenced as a pnpm workspace from the extension components. 🤔 I think I actually prefer this approach as it keeps everything in one place, but I literally just spent the last couple days extracting the shared components from the existing directory in Wasp 🥲 Ah well, I guess that's why we use Git. Thanks for this, it's been very helpful! 🙏🏾

Gaming

Programming

Custom Aliases don't work after migrating from 0.15 to 0.16

Did you find this page helpful?