W
Wasp2mo ago
Zuck

Getting this ts error since updating to wasp 0.17.0

[ Server ] src/actions/addCommentReply.ts(3,33): error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled. [ Server ] src/actions/addToCollection.ts(3,33): error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled. [ Server ] src/actions/aiSynthesis.ts(3,29): error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled. [ Server ] src/actions/analyzeMultiCardRequest.ts(3,41): error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled. [ Server ] src/actions/completeOnboarding.ts(3,36): error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled. [ Server ] src/actions/createCanvasReference.ts(3,39): error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled.
20 Replies
kapa.ai
kapa.ai2mo ago
Hi @Zuck. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- The TypeScript error you're seeing:
error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled.
error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled.
is caused by import statements in your server-side code that end with .ts extensions, e.g.:
import { something } from './someFile.ts'
import { something } from './someFile.ts'
With the current Wasp setup (especially after recent updates and restructuring), TypeScript and Node.js expect import paths in server code to use .js extensions, not .ts. This is due to how ES modules work in Node.js and how TypeScript emits code: TypeScript does not rewrite .ts extensions to .js in import statements, and Node.js cannot resolve .ts files at runtime unless special configuration is used, which Wasp does not currently support by default. This is a known quirk and has been discussed in the Wasp community and issues [Fix inconsistent import extensions in both .wasp file and in JS files.][Look at extension requirements when importing Jobs]. How to fix: - In your server-side TypeScript files, change imports from:
import { something } from './someFile.ts'

import { something } from './someFile.ts'

to:
import { something } from './someFile.js'

import { something } from './someFile.js'

or, if possible, just:
import { something } from './someFile'

import { something } from './someFile'

(but note that sometimes the extension is required, and .js is the correct one to use for server code). This is necessary because TypeScript emits .js files, and Node.js expects to load .js files at runtime. Using .ts in import paths without enabling allowImportingTsExtensions will cause the error you are seeing [Fix inconsistent import extensions in both .wasp file and in JS files.][Look at extension requirements when importing Jobs]. Summary:
Update your server-side imports to use .js extensions instead of .ts. This should resolve the TS5097 error. If you have a lot of imports to update, you may want to use a find-and-replace tool or script to automate this process. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zuck, 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?
Zuck
ZuckOP2mo ago
but i dont ever have ts or js at the end of my imports @kapa.ai
kapa.ai
kapa.ai2mo ago
Let me check the knowledge base for you again. One moment! :books: ---------------------- Thank you for clarifying that you do not have .ts or .js at the end of your import paths. Based on the knowledge sources, Wasp projects (especially after restructuring and updates) have had issues and confusion around import path extensions, particularly for server-side code. The error you are seeing (TS5097) specifically refers to import paths ending with .ts, but if you are not using such extensions, this suggests something else might be happening. From the sources, here are some relevant points: - Wasp and TypeScript expect server-side imports to use .js extensions, or sometimes no extension, but not .ts. If you are not specifying any extension, this should generally be fine, but there have been cases where the build or tooling process rewrites or expects certain extensions, leading to errors [Fix inconsistent import extensions in both .wasp file and in JS files.]. - There have been reports that sometimes, even if you do not write the extension, the generated or compiled code might reference .ts due to how imports are handled or transformed [Improve error messages reported by the framework code]. - The Wasp team has acknowledged that inconsistent handling of extensions has caused confusion and errors, and they have been working to make this more uniform and robust [Fix inconsistent import extensions in both .wasp file and in JS files.]. What you can do: - Double-check your imports to ensure none of them end with .ts (as you mentioned). - Check if any code generation, migration, or codemod scripts may have introduced .ts extensions in the generated files. - If you recently migrated or updated your project (e.g., from 0.11.x to 0.12.x or later), ensure that all import paths in your server code are either extensionless or end with .js, as per the new structure and requirements [Migration from 0.11.X to 0.12.X]. If you are certain that your code does not have .ts or .js at the end of imports, but you are still seeing this error, it is possible that: - The error is coming from generated code or a dependency, not your source files. - There is a misconfiguration in your project or a bug in the Wasp toolchain. If the problem persists, consider: - Running wasp clean to clear any cached or generated files and then rebuilding. - Checking the generated code in .wasp/out/ or similar directories to see if any imports there have .ts extensions. - Reporting the issue with a minimal reproduction to the Wasp team, as this may be a bug or regression in the latest version. The knowledge sources do not provide a definitive answer for your specific situation if you never use .ts or .js in your import paths, but they do confirm that extension handling has been a source of issues in Wasp projects. If you can share a snippet of the relevant import and file structure, it may help further diagnose the issue. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zuck, 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?
Zuck
ZuckOP2mo ago
@kapa.ai any info on wasp 0.17.0?
kapa.ai
kapa.ai2mo ago
Let me check the knowledge base for you again. One moment! :books: ---------------------- I'm sorry, but the knowledge sources provided do not contain any information about Wasp 0.17.0. If you need details about this specific version, I recommend checking the official Wasp GitHub repository or the Wasp documentation site for the latest release notes and updates. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zuck, 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?
Zuck
ZuckOP2mo ago
sigh whyyyyy could it be that i import / define the actions in query with .ts at the end and this is being enforced in 0.17.0 now? @kapa.ai
kapa.ai
kapa.ai2mo ago
Let me check the knowledge base for you again. One moment! :books: ---------------------- Based on the knowledge sources, it is possible that specifying .ts at the end of import paths in your Wasp files (for actions or queries) could cause issues, especially after recent updates and restructuring in Wasp. There is clear documentation and discussion that server-side imports should not end with .ts, and that this has been a source of confusion and errors in the past. The correct approach is to either omit the extension or use .js for server-side imports, as TypeScript does not rewrite .ts to .js in emitted code, and Node.js expects .js at runtime [Fix inconsistent import extensions in both .wasp file and in JS files.][Look at extension requirements when importing Jobs]. While the sources do not explicitly mention enforcement of this rule starting with Wasp 0.17.0, they do indicate that stricter and more uniform handling of import extensions has been a goal in recent updates. Therefore, if you are importing or defining actions/queries with .ts at the end, this could indeed be the cause of the error you are seeing, especially if the new version enforces this more strictly. Recommendation:
Remove the .ts extension from your import paths in Wasp files for actions and queries, and use either no extension or .js as appropriate. This should resolve the issue if it is related to stricter enforcement in the newer Wasp version. If you continue to experience issues, it may be due to changes in how Wasp handles imports internally, and you may want to check the generated code or reach out to the Wasp team for further clarification. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zuck, 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?
Zuck
ZuckOP2mo ago
okay so that was part of it i had to get rid of the .ts from the imports in main.wasp. I also could not name files something like file.action.ts or even file.action in main.wasp. No other periods allowed anywhere in the file name or it causes mayhem. @kapa.ai
kapa.ai
kapa.ai2mo ago
Let me check the knowledge base for you again. One moment! :books: ---------------------- You're correct that having .ts at the end of import paths in main.wasp can cause issues—this is consistent with known problems in Wasp regarding import extensions, especially for server-side code. The knowledge sources confirm that Wasp expects either no extension or .js for server imports, and using .ts can lead to errors, particularly after recent updates that aim for more consistent handling of imports [Fix inconsistent import extensions in both .wasp file and in JS files.][Look at extension requirements when importing Jobs]. Regarding file naming: while the sources do not explicitly mention the restriction on additional periods (dots) in filenames like file.action.ts or file.action, there is evidence that Wasp's import and code generation logic can be sensitive to file naming conventions and structure. Issues have been reported when file names or paths do not match expected patterns, leading to confusing errors or build failures [Fix inconsistent import extensions in both .wasp file and in JS files.]. In summary: - Remove .ts from import paths in main.wasp. - Avoid using extra periods in filenames referenced in main.wasp, as this can cause problems with Wasp's import resolution. If you follow these conventions, you should avoid the "mayhem" and errors you've encountered. If you need more detailed rules, the official Wasp documentation or GitHub issues are the best places to check for updates as the framework evolves. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zuck, 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?
Zuck
ZuckOP2mo ago
is it a general rule not to name files with multiple . 's? Or is this just a wasp bug @kapa.ai
kapa.ai
kapa.ai2mo ago
Let me check the knowledge base for you again. One moment! :books: ---------------------- The knowledge sources do not explicitly state a general rule in Wasp about avoiding multiple periods ('.') in filenames. However, your experience aligns with known issues where Wasp's import and code generation logic can be sensitive to file naming conventions, leading to errors or unexpected behavior if filenames contain extra periods. This suggests it may be a current limitation or bug in Wasp, rather than an intentional, documented rule. If you encounter problems with filenames containing multiple periods, it is safest to avoid them for now. There is no official documentation in the provided sources that establishes this as a general rule, so it appears to be a practical workaround for current Wasp behavior rather than a formal requirement. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zuck, 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?
Zuck
ZuckOP2mo ago
@kapa.ai ya but im just talking about coding in general
kapa.ai
kapa.ai2mo ago
Let me check the knowledge base for you again. One moment! :books: ---------------------- I'm sorry, but the knowledge sources provided do not contain information about general coding practices regarding the use of multiple periods ('.') in filenames outside of Wasp. My expertise is focused on Wasp-specific topics, so I cannot provide a definitive answer about general coding conventions. If you have questions about Wasp, feel free to ask! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zuck, 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?
Zuck
ZuckOP2mo ago
okay now im getting: @kapa.ai
[ Server ] ../../../src/server/apis/image-validation.api.ts(45,85): error TS18046: 'error' is of type 'unknown'. [ Server ] ../../../src/server/apis/image-validation.api.ts(50,22): error TS18046: 'error' is of type 'unknown'. [ Server ] src/routes/apis/index.ts(262,43): error TS2345: Argument of type '{ entities: { User: Prisma.UserDelegate<DefaultArgs>; }; }' is not assignable to parameter of type 'Context'. [ Server ] Property 'user' is missing in type '{ entities: { User: Prisma.UserDelegate<DefaultArgs>; }; }' but required in type 'Context'. [ Server ] src/routes/apis/index.ts(280,51): error TS2345: Argument of type '{ entities: { User: Prisma.UserDelegate<DefaultArgs>; }; }' is not assignable to parameter of type 'Context'. [ Server ] Property 'user' is missing in type '{ entities: { User: Prisma.UserDelegate<DefaultArgs>; }; }' but required in type 'Context'. [ Server ] src/routes/apis/index.ts(298,44): error TS2345: Argument of type '{ entities: { User: Prisma.UserDelegate<DefaultArgs>; }; }' is not assignable to parameter of type 'Context'. [ Server ] Property 'user' is missing in type '{ entities: { User: Prisma.UserDelegate<DefaultArgs>; }; }' but required in type 'Context'. [ Server ] src/routes/apis/index.ts(316,52): error TS2345: Argument of type '{ entities: { User: Prisma.UserDelegate<DefaultArgs>; }; }' is not assignable to parameter of type 'Context'. [ Server ] Property 'user' is missing in type '{ entities: { User: Prisma.UserDelegate<DefaultArgs>; }; }' but required in type 'Context'. [ Server ] src/routes/apis/index.ts(335,49): error TS2345: Argument of type '{ user: AuthUser; entities: { User: Prisma.UserDelegate<DefaultArgs>; }; }' is not assignable to eter of type 'Context'. [ Server ] Property 'user' is mis
kapa.ai
kapa.ai2mo ago
Let me check the knowledge base for you again. One moment! :books: ---------------------- Based on the errors you posted, here’s what the knowledge sources can tell us: 1. 'error' is of type 'unknown' This is a TypeScript error that occurs when you catch an error in a try/catch block without specifying the type. TypeScript treats the caught error as unknown for safety. The knowledge sources do not provide specific guidance on this, as it is a general TypeScript issue, not Wasp-specific. 2. Argument of type '{ entities: { User: Prisma.UserDelegate<DefaultArgs>; }; }' is not assignable to parameter of type 'Context'. Property 'user' is missing... This error is Wasp-related. According to the documentation, the context object injected by Wasp into your APIs, actions, and queries includes both entities and, when authentication is enabled, a user property [Using the context.user object][Defining the API's NodeJS Implementation]. If you are manually constructing a context object for testing or custom code, you must include all required properties, such as user (when authentication is enabled), not just entities. For example:
const context = {
user: { /* user fields here */ },
entities: { User: prisma.user }
};
const context = {
user: { /* user fields here */ },
entities: { User: prisma.user }
};
If you only provide entities, TypeScript will complain that user is missing, as shown in your error. Summary of what to check: - Ensure that wherever a Context is expected, you provide both entities and user (if auth is enabled). - If you are mocking or manually creating a context, include all required properties. If you need more details on the structure of context, see the Wasp docs on context and API implementation. If you need help with the 'error' is of type 'unknown' TypeScript error, the knowledge sources do not cover this, as it is not Wasp-specific. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zuck, 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?
Zuck
ZuckOP2mo ago
From my AI Agent:
Zuck
ZuckOP2mo ago
Zuck
ZuckOP2mo ago
This is fixed. Errors stemmed from new tsconfig paramaters and express 5 requirements. As well as a couple wasp bugs. But also keep in mind my code standards aren't great, so people likely won't run into these issues often. The only thing I could think stupid proofing is making it easier to figure out not to put .s in file names especially actions and queries
miho
miho2mo ago
I'm glad you migrated successfully, what was the AI agent you used to migrate? That seems pretty cool and potentially useful for others 🙂
Zuck
ZuckOP2mo ago
@miho I use Augment Code! Highly highly recommend The main thing they do differently that sets them apart is they have a context engine that understand large codebases realllly well

Did you find this page helpful?