Closed ErKeLost closed 8 months ago
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.
hi @phoenix-ru Is support for unplugin already under way? I'd like to be involved if I can.