hey there 👋 it seems you got quite inspired by es-dev-server 🤗

is there may be room to collaborate? having full support for vue within es-dev-server via a middleware or a "plugin" would certainly sound great 💪

now it seems more like becoming a "fork" with baked in vue features? 🤔

A possible starting point would be a transformer like this

module.exports = {
  responseTransformers: [
    async function processVueFiles({ url, status, contentType, body }) {
      if (url.endsWith('.vue')) {
        const rewritten = await processingVueFile(body);
        return { body: rewritten };
      }
    },
  ],
};

but for more advanced features a koa middleware would be more appropriate.

I am somewhat confident that a koa middleware and/or a babel plugin will have sufficient power to tackle this task... and even if not we would be more then willing to provide additional hooks for vue if needed 🤗

Feel free to discuss here or you can also shoot me a private message on twitter (dms are open) https://twitter.com/daKmoR

Thanks for reaching out! I actually tried a branch doing exactly that but lacked some access to the internals (most importantly, the server config) from a config middleware. The most defining part of this project is actually the hot module replacement for Vue components, not just the file transform.

Another pain point is that although es-dev-server is internally typed using jsdoc, it doesn't generate type definitions for consumers, and I kinda have to shim everything myself.

It would be great if es-dev-server can support a plugin format similar to what I have right now: a function that receives the koa app instance, the raw http server, and the resolved config object. I think that would provided everything I need to add Vue support to es-dev-server.

Thanks for your concerns I am sure we can resolve them 🤗

Regarding the types, I thought we already published them 🙈 (we do so for other packages) I will look into that 👍

Right now a middleware is basically a 1 to 1 mapping to a koa middleware - which does not really care about the dev server config indeed 😅

We could offer a similar "helper" as transformers but on middleware level - that way you could get access to the config.

how about this strawman proposal? Note: we are also discussing the API of a full plugin so your use case is very valuable to us 🤗

async function myPlugin(ctx, next, config) { // just a middleware with config?
  console.log(config); // es-dev-server config
  await next();
}

what you could do right now is to use es-dev-server programmatically: https://open-wc.org/developing/es-dev-server.html#using-es-dev-server-programmatically

something like this could work: warning this is psoido code - e.g. untested

import Koa from 'koa';
import { createConfig, createMiddlewares } from 'es-dev-server';

function createVueMiddelware(config) {
  return (ctx, next) => {
    // now has access to config
  }
}

const config = createConfig({
  // ...
});

config.middlewares.push(createVueMiddelware(config));
const middlewares = createMiddlewares(config);

const app = new Koa();
middlewares.forEach(middleware => {
  app.use(middleware);
});

PS: if there are any other questions please let me know 🤗

The "middleware with config" strawman still lacks the ability for a plugin to do one-time setup work, since the middleware is called repeatedly on every request. An example of the one-time setup work would be hooking into the file watcher and the http server to handle custom HMR notifications.

The lower level API based usage looks straightforward though, I might give that a crack later on.

fair enough we will look more in depth into it and make sure to come up with something that will support it 👍

Hey, just chiming in, since I'm working on a project similar to both of these: https://github.com/lastmjs/zwitterion. Perhaps we can collaborate or share ideas.

Zwitterion goes beyond development and allows production builds, which are essentially static builds that you deploy on a CDN. Also, using WebAssembly Zwitterion provides support for languages like C, C++, and Rust.

Closing as I've written a bit more on why vite is its own project: https://github.com/vuejs/vite#how-is-this-different-from-es-dev-server

Obviously still open to potentially adding Vue support to es-dev-server - many parts of vite could probably be reused for that.