kapa.ai
Cache Policy
The
immutable
flag tells browsers that the file will never change, which improves caching efficiency.
Additional Considerations
If you're using Nuxt Image with a specific provider like Vercel or AWS Amplify, they have their own caching mechanisms. For example, Vercel's Edge Network automatically optimizes images when you deploy to their platform, as mentioned in the Vercel provider documentation.
If you're generating a static site, Nuxt Image will optimize and save your images locally during generation, as noted in the Static Images documentation.
Remember that if you're using the dir
option to change where Nuxt Image looks for source images (e.g., from public
to assets/images
), this might affect how caching works for certain providers:
This configuration is explained in the dir configuration documentation.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------5 replies
Cache Policy
----------------------
I'll help you set up proper cache policies for your public images and Nuxt Image generated assets.
Caching Public Images and Nuxt Image Assets
For images in the
/public
directory and those generated by NuxtImg
with the sizes
attribute, you have a few options:
1. For Nuxt Image Generated Images
Nuxt Image uses the IPX provider by default which handles image optimization. When using NuxtImg
with the sizes
attribute, it generates optimized versions of your images that are served from the /_ipx/
path.
These images are automatically cached by the browser based on the response headers. You can configure caching behavior through Nitro's route rules:
This configuration enables server-side SWR (stale-while-revalidate) caching for all images processed by Nuxt Image.
2. For Static Assets in Public Directory
For regular images in your /public
directory, you can set similar cache rules:
3. For _nuxt Assets
For assets in the _nuxt
directory (which contains your bundled JavaScript, CSS, and other assets), you can set:
5 replies
cannot import 'useApollo' composable from another composable
----------------------
I understand your frustration! This is indeed a common issue with Vite and ESM modules in Nuxt. The
.mjs
extension is crucial for proper ESM resolution.
This relates directly to how Nuxt and Vite handle ES Modules. As mentioned in the ES Modules documentation, sometimes you need to manually alias libraries to their correct file paths with extensions.
For your case, you needed to specify the .mjs
extension when importing from the module. This is a common pattern when working with ES Modules in Node.js environments.
You could have resolved this by adding an alias in your nuxt.config.ts
:
Or by directly importing with the correct extension:
These small details with file extensions can be incredibly frustrating to debug, especially when the error message isn't entirely clear about what's wrong. At least now you know for future reference!
I'm glad you found the solution, even if it was a seemingly simple fix after two days of troubleshooting.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------34 replies
WWasp
•Created by Webby Vanderhack on 3/29/2025 in #🙋questions
Should migration.sql files be checked in to git?
Sorry @Webby Vanderhack, 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?
4 replies
WWasp
•Created by Webby Vanderhack on 3/29/2025 in #🙋questions
Should migration.sql files be checked in to git?
----------------------
Yes, migration files should be checked into git when working with Wasp projects.
Based on the knowledge sources, migrations are considered part of the source code in Wasp. This is evident from issue #105 which states that "migrations/ can also be considered to be part of a source code" Generator should copy migrations folder.
Additionally, the discussions in various issues indicate that migrations are meant to be versioned and shared between developers:
1. In issue #211, there's discussion about propagating deletion of migrations from the source to the generated project, which implies migrations are part of the versioned source code Propagate deletion of db migrations.
2. Issue #214 mentions storing "the last migrated checksum in such a way that it is versioned in the Wasp project dir and propagated up/down" which further suggests migrations are meant to be versioned Warn user if Prisma needs to be re-generated.
Unlike temporary files created by API endpoints (mentioned in issue #1881), which should be gitignored, migration files represent the evolution of your database schema and should be shared across all development environments.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
4 replies
WWasp
•Created by Webby Vanderhack on 3/29/2025 in #🙋questions
Should migration.sql files be checked in to git?
Hi @Webby Vanderhack. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
4 replies
cannot import 'useApollo' composable from another composable
4. Check for Nuxt/Apollo version compatibility
This could be related to a compatibility issue between Nuxt 3.16.0 and the Apollo module, similar to what was reported with Algolia in this GitHub issue.
5. Use the #imports alias
If none of these solutions work, it might be worth checking if there's a specific issue with the version of
@nuxtjs/apollo
you're using, or if there are any reported issues in their GitHub repository.
The fact that the file exists but Vite can't resolve it suggests this is more of a module resolution or bundling issue rather than a missing file problem.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------34 replies
cannot import 'useApollo' composable from another composable
----------------------
I understand your frustration with this import issue. This appears to be related to how Vite resolves modules in Nuxt, particularly with dynamically imported modules.
Based on the information in the knowledge sources, there are a few potential causes and solutions for this issue:
Possible causes:
1. Chunk loading errors: This could be similar to the issue described in this GitHub issue where Nuxt fails to resolve file paths correctly.
2. Vite import conditions: There was a fix in Nuxt related to Vite import conditions as mentioned in this PR, which resolved issues with import resolution.
3. Path aliases: The error shows an absolute path being used instead of module resolution, which suggests an issue with how the module is being imported.
Solutions to try:
1. Use auto-imports instead of direct path
Instead of importing directly from the module path, rely on Nuxt's auto-import system:
2. Configure explicit imports in nuxt.config.ts
You can explicitly tell Nuxt to import from the Apollo module:
As shown in the Auto-import from Third-Party Packages documentation.
3. Try transpiling the module
If the module is having issues with ESM compatibility:
34 replies
cannot import 'useApollo' composable from another composable
As described in the Auto-import from Third-Party Packages documentation.
This issue might be related to how Vite resolves imports or a potential bug in the auto-import system. If none of these solutions work, you might want to check if there are any reported issues with the
@nuxtjs/apollo
module or consider using a different approach to access the Apollo client.
Let me know if any of these solutions help resolve your issue!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------34 replies
cannot import 'useApollo' composable from another composable
----------------------
I understand you're facing an issue with importing the
useApollo
composable from the @nuxtjs/apollo
module. This appears to be related to how Nuxt handles auto-imports and module resolution.
The error you're seeing suggests that Vite is trying to resolve the import using an absolute file path rather than through the module's proper export mechanism. This is not how Nuxt's auto-imports are meant to work.
Possible solutions:
1. Use the auto-imported composable directly
Since you're using @nuxtjs/apollo
, the useApollo
composable should be auto-imported by the module. Try removing the explicit import and just use it directly:
2. Use the #imports alias
If you need to make the import explicit, use the #imports
alias which Nuxt provides for all auto-imports:
As mentioned in the Nuxt documentation:
Nuxt exposes every auto-import with the #imports
alias that can be used to make the import explicit if needed.
Auto-imports documentation
3. Check module configuration
Make sure the Apollo module is properly configured in your nuxt.config.ts
file. The module should be setting up its auto-imports correctly.
4. Check for third-party package auto-imports
If the above solutions don't work, you might need to explicitly configure auto-imports for the Apollo module. You can do this in your nuxt.config.ts
:34 replies
cannot import 'useApollo' composable from another composable
You cannot use them outside a Nuxt plugin, Nuxt route middleware or Vue setup function. On top of that, you must use them synchronously.Nuxt documentation If you need to maintain a singleton instance, you might consider using a Nuxt plugin instead, as shown in this Stack Overflow answer: Then you can access it in your composable using
useNuxtApp().$yourApi
.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------34 replies