One caution with Greenwood resource plugins is making sure not to "overlay" match and / or interfere with userland plugins in unexpected ways, partially due to having to rely (only) on extensions for knowing what kind of file a request / resource is. For example, there is a case where two files could have the same extension, like our TypeScript plugin and say if a user had a plugin to support MPEG streams, which could both use .ts extension.
One way Web APIs can help us with that now by sending a header with information about the resource, like if it is a video file, and that is the Sec-Fetch-Dest header.
Here could be an example for our audio resource plugin
I think we should apply this to all plugins for consistency, which also means we should be able to remove this break statement we put into the dev server to avoid multiple plugins trying to incompatibly handle the same resource.
We will also need to update some test cases I imagine to send this header explicitly.
Summary
One caution with Greenwood resource plugins is making sure not to "overlay" match and / or interfere with userland plugins in unexpected ways, partially due to having to rely (only) on extensions for knowing what kind of file a request / resource is. For example, there is a case where two files could have the same extension, like our TypeScript plugin and say if a user had a plugin to support MPEG streams, which could both use .ts extension.
One way Web APIs can help us with that now by sending a header with information about the resource, like if it is a video file, and that is the
Sec-Fetch-Dest
header.Here could be an example for our audio resource plugin
Details
I think we should apply this to all plugins for consistency, which also means we should be able to remove this
break
statement we put into the dev server to avoid multiple plugins trying to incompatibly handle the same resource.We will also need to update some test cases I imagine to send this header explicitly.