bug: NuxtImage not installed by module

[kheiner]

Testing a minimal reproduction for another issue & uncovered:

Steps to reproduce:

1. Install Nuxt npm create nuxt@latest without adding any optional features.
2. Install nuxt-directus-sdk npm install nuxt-directus-sdk add it to modules in nuxt.config.ts
3. npm run dev

---

It looks like the installModule() was removed from module.ts in this commit. Current next branch code should have it re-added on the conditional - I think that's the source of the problem and is a simple fix.

nuxt-directus-sdk/src/module.ts

Lines 357 to 377 in d2715ed

	// Register @nuxt/image with Directus provider
	const imageConfig = typeof options.image === 'boolean' ? { enabled: options.image } : options.image
	const imageEnabled = imageConfig?.enabled ?? true
	if (imageEnabled) {
	const { setDefaultProvider, modifiers } = imageConfig || {}
	const imageBaseUrl = devProxyEnabled
	? `${devProxyPath}/assets`
	: useUrl(clientUrl, 'assets')
	await registerModule('@nuxt/image', 'image', {
	// Set default provider if requested
	...(setDefaultProvider && { provider: 'directus' }),
	// Configure Directus provider
	directus: {
	baseURL: imageBaseUrl,
	modifiers,
	},
	})
	}

Happy to fix but before I do, I want to make sure I'm not taking down Chesterton's Fence. Why was it switched?

Originally posted by @kheiner in #2

[kheiner]

It looks like nuxt/kit deprecated installModule() as of 4.1.0.

Module compatibility is listed as 4.0.0

nuxt-directus-sdk/src/module.ts

Lines 190 to 191 in bb0a3fc

	compatibility: {
	nuxt: '^4.0.0',

With a matching dependency in package.json

nuxt-directus-sdk/package.json

Lines 58 to 59 in bb0a3fc

	"dependencies": {
	"@nuxt/kit": "^4.0.0",

Warning

devDependency does not match 4.0.0

nuxt-directus-sdk/package.json

Line 79 in bb0a3fc

"nuxt": "^4.1.2",

To fix this issue appropriately, it will mean bumping the compatibility to at least 4.1.0 - I don't see any other issues with bumping and using the recommended fix of moduleDependencies:

export default defineNuxtModule({
  meta: {
    name: 'my-module',
  },
  moduleDependencies: {
    'some-module': {
      // You can specify a version constraint for the module
      version: '>=2',
      // By default moduleDependencies will be added to the list of modules 
      // to be installed by Nuxt unless `optional` is set.
      optional: true,
      // Any configuration that should override `nuxt.options`.
      overrides: {},
      // Any configuration that should be set. It will override module defaults but
      // will not override any configuration set in `nuxt.options`.
      defaults: {}
    }
  },
  setup (options, nuxt) {
    // Your module setup logic
  }
})

[kheiner]

The bug only presents itself when nuxt-directus-sdk is installed without also manually installing @nuxt/img and leaving the default for image:

nuxt-directus-sdk/src/module.ts

Line 200 in bb0a3fc

image: true,

Could be mitigated by making false the default for image.

[matt-rolley]

I wonder if we try to use tryResolveModule, like with the visual editor? I don't think this will fail if it's not installed. I think this issue is the fact we moved it to an optional peerDepenency, incase users had already added the library.

Or, like you say, perhaps we set it to false? but I think tryResolveModule might be the way to go.

[kheiner]

I'm not sure tryResolveModule() will address the case where it's not installed manually and the default is left to true. It will prevent the error but not install the module. I suppose there's a conditional we can evaluate if tryResolveModule returns undefined (the promise does not return a string) then it can trigger to install the module using the 4.0.0 capable installModule().

I see two paths here:

Path 1: Retain Nuxt 4.0.0 compatibility

• Change the devDependency from 4.1.2 to 4.0.0 (currently the devDependency doesn't match versions for nuxt compatibility or the nuxt/kit)
• Add the tryResolveModule as a catch for whether or not the dependency is installed and only use installModule() in the case that tryResolveModule returns undefined. This preserves the users ability to have a version of @nuxt/image different than ^2.0.0.

Path 2: Bump Nuxt to 4.1.0 (or further?)

• Update nuxt compatibility to 4.1.0 and use nuxt/kit 4.1.0 - downgrade devDependency to 4.1.0 to match.
• Use the new moduleDependencies option to manage @nuxt/image install/version. This has the added bonus of adding the @nuxt/image into the defineNuxtConfig modules array.

Path 1 is great for backwards compatibility at the expense of complexity.
Path 2 is simpler but does mean that some users who are using nuxt 4.0.0 - nuxt 4.1.x (whatever version is chosen) will need to upgrade their nuxt instance to add the nuxt-directus-sdk module. This may have an impact to you/your organization since I imagine your teams have been using this module the longest and are most likely to be on a nuxt version between 4.0.0 and 4.1.0.

So the question is more: Does your team need backwards compatibility to 4.0.0 or should the module consider that most users are going to create a new next project and install the directus-sdk-module in a clean environment.

In either case, I think the module should not set the image flag as true by default and the simplest fix is to modify the default so that users who encounter the error are doing so intentionally. Thoughts?

[matt-rolley]

Yeah, I was thinking we'd use the tryResolveModule as part of the check to then run installModule if tryResolveModule is true and it's enabled? A bit like:

nuxt-directus-sdk/src/module.ts

Line 84 in bb0a3fc

* Set Directus as the default provider for NuxtImg

But as I think as we're going to 5.0.0, we could quite safely introduce a breaking change (requiring nuxt 4.1.0), so I think that might be the way to go?

[kheiner]

Sounds good. I'll take on the task of the bump pushing to next.

[kheiner]

I got a little distracted with downstream problems here but submitted a PR to @nuxt/image to have the Directus Provider type appropriately. I'm still planning on doing this but don't have a solid grasp on the timeline.

[matt-rolley]

No worries at all, just let me know when you're ready and we'll get it merged in. I think we're all good on version 5 now, so I'm going to push that live :) Thanks for all your help on this one!