Wasp•5mo ago

Module Resolution Setting being weird?

I got this error when attempting to use state-in-url:

import {useUrlState} from "state-in-url/react-router";

import {useUrlState} from "state-in-url/react-router";

Error:

[  Wasp  ] page.tsx(9,27): error TS2307: Cannot find module 'state-in-url/react-router' or its corresponding type declarations.
[  Wasp  ]   There are types at 'app/node_modules/state-in-url/dist/react-router/index.d.ts', but this result could not be resolved under your current 'moduleResolution' setting. Consider updating to 'node16', 'nodenext', or 'bundler'.

[  Wasp  ] page.tsx(9,27): error TS2307: Cannot find module 'state-in-url/react-router' or its corresponding type declarations.
[  Wasp  ]   There are types at 'app/node_modules/state-in-url/dist/react-router/index.d.ts', but this result could not be resolved under your current 'moduleResolution' setting. Consider updating to 'node16', 'nodenext', or 'bundler'.

tsconfig has moduleResolution set to bundler. Using the TS Spec, if that makes a difference.

4 Replies

kapa.ai•5mo ago

Hi @Zeke. 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 knowledge sources provided, there is no explicit information about the specific error you are encountering with the module resolution setting for TypeScript in Wasp, especially regarding the use of the bundler setting and the state-in-url package. However, there are some related insights: - Wasp projects use TypeScript and ES Modules, and there have been issues in the past with module resolution, especially around extensions and compatibility with certain module systems. For example, ESNext modules require explicit file extensions in imports, and TypeScript does not rewrite these extensions during emit, which can cause issues if the expected file is not found or if the module system is not configured correctly. This is a known quirk of the TypeScript/ESM ecosystem, not specific to Wasp itself, and is discussed in the context of import paths and module resolution in Wasp projects. The recommendation is to ensure your imports use the correct extensions and that your tsconfig is aligned with your project's module system requirements. Switching to an older module system like CommonJS is not recommended for Wasp projects, as ES Modules are the standard going forward and are required for features like top-level await and compatibility with Vite and Node.js ESM support Look at extension requirements when importing Jobs. - There is no mention in the sources of the state-in-url package or its compatibility with Wasp or its default TypeScript configuration. - The error message you are seeing suggests that TypeScript cannot resolve the module under your current moduleResolution setting, even though the type definitions exist. The message itself suggests trying node16, nodenext, or bundler as possible values for moduleResolution, but there is no information in the sources about which of these is best supported or recommended in Wasp. In summary, the knowledge sources do not contain enough information to provide a definitive answer or solution to your specific module resolution issue with state-in-url in Wasp. You may need to experiment with the moduleResolution setting or consult the documentation for both Wasp and the state-in-url package for further guidance. If you continue to encounter issues, consider reaching out to the Wasp community for more targeted support. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zeke, 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?

miho•5mo ago

@Filip woud you mind answering this one, I feel like you could better answer all the details regarding tsconfig.json

Filip•5mo ago

Hmm, this is weird because you say you do have bundler Oh, I see, the error is probably coming from .wasp/out/sdk/wasp/tsconfig.json @Zeke there's a comment above the module resolution that explains the problem I'll paste it here:

    /*
       The correct `moduleResolution` option is `bundler` because:
         - We want to allow users to use extensionless and directory imports.
         - We want users to import stuff from the SDK with `wasp/something`,
           and we don't want to do extra processing on those imports (for now).

       These requirements force us to bundle user code and, because we copy user
       code into the SDK code, they force us to bundle the SDK too.

       We currently bundle the SDK in a very hacky way (indirectly while bundling
       the server and client): https://github.com/wasp-lang/wasp/issues/2150
       Regardless of how we do it, the SDK code is eventually bundled, so this
       `tsconfig.json` file must reflect that (which means `moduleResolution:
        bundler`).

       Unfortunately, setting `"moduleResolution": "bundler"` doesn't work due
       to an issue with stitches: https://github.com/stitchesjs/stitches/issues/1160.

       "node10" models the resolution of Node.js <= 12, but also happens to be a
       passable approximation of how most bundlers do module resolution (and allows
       all the bundler features we want to support).
       Since we can't have "bundler", "node10" is the next best thing.
       Source: https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution

       TODO: Change "moduleResolution" to "bundler" when we move away from stitches.
    */

    /*
       The correct `moduleResolution` option is `bundler` because:
         - We want to allow users to use extensionless and directory imports.
         - We want users to import stuff from the SDK with `wasp/something`,
           and we don't want to do extra processing on those imports (for now).

       These requirements force us to bundle user code and, because we copy user
       code into the SDK code, they force us to bundle the SDK too.

       We currently bundle the SDK in a very hacky way (indirectly while bundling
       the server and client): https://github.com/wasp-lang/wasp/issues/2150
       Regardless of how we do it, the SDK code is eventually bundled, so this
       `tsconfig.json` file must reflect that (which means `moduleResolution:
        bundler`).

       Unfortunately, setting `"moduleResolution": "bundler"` doesn't work due
       to an issue with stitches: https://github.com/stitchesjs/stitches/issues/1160.

       "node10" models the resolution of Node.js <= 12, but also happens to be a
       passable approximation of how most bundlers do module resolution (and allows
       all the bundler features we want to support).
       Since we can't have "bundler", "node10" is the next best thing.
       Source: https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution

       TODO: Change "moduleResolution" to "bundler" when we move away from stitches.
    */

The short version is: Wasp SDK cannot have module resolution set to bundler because of our dependency on stitches We have plans to move away from stitches here: https://github.com/wasp-lang/wasp/issues/1565 I've mentioned this Discord thread in the issue to help prioritize it Now, how can you solve this error for yourself in the immediate future, let me think I'm guessing the best bet is somehow patching the state-in-url/react-router to work with moduleResolution: node10 Would that work for you @Zeke? Thanks for the patience btw, I know this is pretty ridiculous

ZekeOP•5mo ago

ohh alrighty no worries. I'll switch to using nuqs instead, it seems like it'll work just as well

Gaming

Programming

Module Resolution Setting being weird?

Did you find this page helpful?