wasp-lang / wasp

The fastest way to develop full-stack web apps with React & Node.js.
https://wasp-lang.dev
MIT License
13.71k stars 1.18k forks source link

Adding an import from wasp/server/operations on server side code is causing the build to fail on relative imports #2271

Closed walt93 closed 1 month ago

walt93 commented 1 month ago

Describe the bug This is kind of a weird problem. It's probably user error but it triggers a bug that breaks the build in a bad way.

To Reproduce I added this exact line of code to my server side:

import { subtractCredits } from 'wasp/server/operations';

Adding just this line, not even calling it, causes the compilation to break on* relative imports. Removing the import fixes the build. Changing to import from the source file directly fixes the build, at the loss of functionality & having to pass proper context, etc. and is a sub-optimal workaround.

In main.wasp, subtractCredits is defined as:

action subtractCredits {
  fn: import { subtractCredits } from "@src/payment/creditManagement.ts",
  entities: [User]
}

In creditManagement.ts, the function is defined as:

export const subtractCredits = async (args, context) => { ... }

This boilerplate may have even been from the SaaS example template now that I think about it.

I am not sure what else in the project may have contributed to this. Will update this report if&when I find it…

Expected behavior Whatever broke the build, to report as an error.

*seemingly all relative imports are broken, I went briefly down the rabbit hole of fixing them before doing git archaeology to find this LOC - I therefore suspect something else in the project may be causing this, I just don't know what. I believe this code worked at some point, but when I merged the feature branch back in - I have this. To be continued.


Update: tried a different pattern, importing operations directly, and learned that whatever contamination also breaks relative import compilation - happens if I import operations from 'wasp/server/operations';

Martinsos commented 1 month ago

Thanks for reporting @walt93 ! This reminds me of a bug we had before but fixed -> maybe it returned, or maybe you are using a bit older version of Wasp? Could you let us know which version of Wasp are you using here?

@sodic

sodic commented 1 month ago

Hey @walt93, thanks for the report.

I have a couple of questions:

Thanks!

walt93 commented 1 month ago

Unfortunately I don't have much more data, moving fast and breaking things, I had a feature branch with a dozen new files and schema changes. That import AND something else triggered it. I wasn't able to isolate the "something else" after several hours and ended up dropping diffs to recover. I'm  def on 14.0 and sorry to report there may be another X that can trigger it. Probably, some misteak (sic.) in my code I am sure - I'm a react noob! I wish I could offer more info but there were too many haystacks to search and I'm not sure how to get back to that state. :-(On Sep 9, 2024, at 3:46 AM, Filip Sodić @.***> wrote: Hey @walt93, thanks for the report. I have a couple of questions:

What version of Wasp are you using? This is important because this sounds exactly like an error that was fixed with 0.14.0 (details). If you're using Wasp newer than 0.14.0:

Can you share your project with me (we can do it over a private channel, like Discord DMs)? I can't reproduce the error. If not, can you share the exact error message you're getting?

Thanks!

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>