support `unplugin`
ErKeLost opened this issue · comments
hi @phoenix-ru Is support for unplugin already under way? I'd like to be involved if I can.
Hi @ErKeLost. I have Webpack Dev/Prod/HMR working via unplugin and Virtual Modules.
I intend to get Vite working as well, so any help would be appreciated.
Farm native plugin is also planned
Hi @phoenix-ru I want to create a project under unplugin. Do you think that's okay? so we can support vite rollup farm rspack webpack esbuild. If you agree with this idea, you may need your help to give the repo a name. I'll do the rest of the work. Farm's native support will also be launched immediately. Farm has done most of the work.
That would be great. What about unplugin-vue-fervid?
How else can I help you? You can gain insights about the existing unplugin in node folder, both the implementation and the usage.
That's a great name. I'll start the project as soon as possible. I'll take a look at the api on the node side. If you have any questions, I'll ask you in time.
@ErKeLost Thanks. The existing Node API isn't fully stable yet. For the sake of performance and compatibility I will change the interface to a class instance which stores the options, something like:
// During unplugin crration
const compiler = new Fervid({
isProd: true,
// other options
})
// during transform
compiler.compile(source)It would be great if I can make such changes before Fervid is 1.0. What do you think?
P.S. Please ping me or create an issue/PR so I add your plugin to Readme when it's ready.
hi @phoenix-ru This is the repo address unplugin-vue-fervid.
I have seen that the example in our current repo is the direct use of compilerSync, so should I continue to use this for development or wait for you
// During unplugin crration.
Const compiler = new Fervid ({.
IsProd: true.
// other options.
}).
// during transform.
Compiler.compile (source).What about when this api is ready?
Hi @ErKeLost.
I can probably change the API to the new one today or in the next few days. I'll ping you when ready
@ErKeLost I published @fervid/napi@0.2.0 with the mentioned changes. I also updated node/unplugin to the desired usage.
Btw, compiler.compileAsync is non-blocking and therefore generally faster even on default 4 libuv threads (11.6K ops/sec vs 6.5K ops/sec). If you know how to make an async plugin, I would encourage to use that. Maybe behind a flag async: true (default: true)?
@phoenix-ru It's so exciting. I see that I can already use the compiler class syntax. Our api should be stable for the time being, and it shouldn't change much in the future. If that's the case. I should be able to develop it.