Wrong output path when building in Laravel project

[zepfietje]

First of all, thank you for creating and maintaining this package, @JonasKruckenberg!

I'm trying to use it to process images in a Laravel project.
It works fine in dev mode using npm run dev (vite), but there's an issue when building assets for production using npm run build (vite build).

After installing vite-imagetools, the relative asset paths become absolute, breaking the URLs used in the Laravel Blade views. I've created a simple reproduction repository to show what happens. Have a look at the commits and my explanation below:

1. First, I'm adding an image to the resources/images directory: zepfietje/imagetools-laravel-issue@4141c18.
2. Next, when building the assets, the manifest.json file contains the full path to the image: zepfietje/imagetools-laravel-issue@12b7124.
3. Then, vite-imagetools is installed: zepfietje/imagetools-laravel-issue@4bd7192.
4. And the desired width of the image is set: zepfietje/imagetools-laravel-issue@ad66934.
5. When building again, the asset path in manifest.json loses it's relative directory and becomes absolute, breaking any references if you'd use resources/images/foo.jpg in your views: zepfietje/imagetools-laravel-issue@cd58c93.

I'm not sure if this issue is caused by this package, Vite, or the Laravel plugin for vite. Hopefully you don't mind a mention here @timacdonald, since you fixed a similar issue in the past. Let me know if there's anything I can do to help resolve this issue. 😊

[benmccann]

There was a prior laravel issue. Please ensure you're using a version that includes that fix: #396 (comment)

[zepfietje]

I’m aware of that previous issue, though it doesn’t seem directly related (it’s about the dev server, not building for production).

The latest versions of all dependencies still show the issue I just reported here.

[timacdonald]

Hey, folks, I've just taken a look at this to try and pinpoint where the issue is.

I removed the Laravel plugin npm remove laravel-vite-plugin and update the config to the following:

import { defineConfig } from 'vite';
import { imagetools } from 'vite-imagetools';

export default defineConfig({
    plugins: [
        imagetools(),
    ],
    build: {
        manifest: true,
        rollupOptions: {
            input: ['resources/css/app.css', 'resources/js/app.js']
        }
    }
});

This completely removes any impact on Vite from the Laravel side of things.

I then proceeded to build npm run build:

Looks like the issue persists. Not sure what is going on here. Maybe something to do with the image library and the use of import.meta.glob?

[zepfietje]

Thanks for checking this out so quickly, @timacdonald! 🙌

IIRC, I tried the other documented way of importing the image, and it resulted in the same issue:

import Image from 'example.jpg?w=400&h=300&format=webp'

It seems to work fine when not specifying any query parameters (using either approach). I'm completely new to the internals of Vite and Vite plugins, but to me this proves it's either caused by Vite imports with query parameters, or something goes wrong in this plugin.

Is there anything I can do to dig deeper, @benmccann?

[zepfietje]

Alright, so this issue does indeed only occur when images are processed by this package. Could anyone point me at a place to start debugging this package's source, @JonasKruckenberg?

[benmccann]

The URL gets built here:

imagetools/packages/vite/src/index.ts

Line 172 in 2da03b2

name: basename(pathname, extname(pathname)) + `.${metadata.format}`,

I often find it easiest to just go into node_modules and update the code there to experiment with changes. You could also pull in the project with a pnpm override or pnpm link.

[zepfietje]

Thanks, @benmccann!
I've found a way to change the URL into the format I'd expect (resources/images/foo.jpg, relative to the Vite config root).

I suppose this could be a breaking change for the package, though are you open to this change?

[benmccann]

I'm not sure it's a breaking change. It sounds like a bug fix that users shouldn't notice. Worst case we could cut a new major though, so I'm open to a fix in either case

[zepfietje]

I've created a PR with the changes I made locally to fix the output paths, @benmccann: #743.

There's still some other issues in dev mode with Laravel, but I've worked around that in my own app for now and may create a new issue/PR for that later (if this package appears to be the root cause).