would it be better to first try with decodeURI and then without?

decodeURI change was introduced in #4728, with other places than this so other places might need to be updated too

I think that makes sense too. Like some sort of tryDecodeURI utility. The only other place I found which might hit the decode error was viteServeStaticMiddleware, but that middleware is instantiated after viteTransformMiddleware (where this PR fixes), so this PR would indirectly cover viteServeStaticMiddleware too

i just found that there's already a errorMiddleware which can handle the error and prevent crash🤣, whether in transformMiddleware or serveStaticMiddleware, looks like this:

so i correct the return with next(e) , so the error can be passed to the errorMiddleware to handle it:

after passing to errorMiddleware, therefor we don't need to specifically address this type of error in all places.

@bluwy @patak-dev what do you think is best fallback or showing error message?

Looking back now, I think showing an error message may be safer, since having a fallback might imply that we support it, which we might not. So using next(e) looks good to me. Neat solution too.

@toSayNothing Re viteServeStaticMiddleware, I'm taking back what I said 😅 viteTransformMiddleware can be skipped, so we need to handle decodeURI for viteServeStaticMiddleware too:

@bluwy 🤣i have debugged and found that :
connect can handle the Synchronization function 's error , but not the Asynchronous function .
viteServeStaticMiddleware is sync, so it can handle by the connect itself(call try catch)
but the async viteTransformMiddleware will crash the server if not handly by catch(e){return next(e)}

online connect repo : https://stackblitz.com/edit/node-w8ukhk

Nice observation @toSayNothing. That's an interesting behaviour from connect. It would sure be nice if it handles promises too, but for now this looks good to me.