Resolving ext-src imports in the SDK if the user declares an import with the .js ext

[infomiho]

Users get a weird error saying they can't import queries.js.js something something.

I've reproduced with the latest Wasp version: 0.13.2

As far as I can see, it seems related to the exports fields and the ext-src/* entry 😄

Two instances on Discord:

• https://ptb.discord.com/channels/686873244791210014/1250145383322091561/1250145383322091561
• https://ptb.discord.com/channels/686873244791210014/1249857194925752401/1249857194925752401

[Martinsos]

Sending this back to triage, multiple people had this and error message is quite confusing, we should take care of it.

[Martinsos]

This is in a way related to #2087 , as they might share a solution, which is us completely forbidding, in main.wasp, to have .js or .ts extensions in ext imports, or, another solution, somehow additionally processing extensions to fit with what Wasp requires.

[Martinsos]

User said following:

Was odd because the issue was nonexistent until one day it wasn't.

That is peculiar! Might it mean that one of the deps updated minor version and caused this that way?

[sodic]

That is peculiar! Might it mean that one of the deps updated minor version and caused this that way?

The error is only triggered when you import an operation from wasp/server/operations into server code that gets used (e.g., the server setup function or an API call). Here's a minimal repro example.

You need the following Wasp file:

app extension {
  wasp: {
    version: "^0.14.0"
  },
  title: "example",
  server: { setupFn: import { setup } from "@src/setup" }
}

// ...

action jsAction {
  fn: import { jsAction } from "@src/jsAction.js"
}

And the following code in setup.js:

import { jsAction } from "wasp/server/operations";

export function setup() {
  console.log(jsAction);
}

The error only happens when:

• setup.js imports jsAction from wasp/server/operations
• main.wasp somehow uses setup.js.
• The jsAction declaration includes a .js extension in the file name.
• The user is using Wasp older than 0.14.0.

If any of the conditions aren't met, there's no error. You need all four to trigger it.

This is probably why our user felt the issue appeared out of thin air - it was caused by something seemingly unrelated.

Since this specific was fixed with Wasp 0.14.0 thanks to this change introduced in commit c184a9b, I'm closing the issue.

We still have other extension-related problems which I'll cover in a different issue.