feat: expose moduleRewrite and compileSFCStyle #104
Conversation
|
This doesn't add it to the main |
|
That's because currently because we use I will add to index |
pikax
changed the title
src/node/server/index.ts
Outdated
| @@ -13,6 +13,8 @@ import { assetPathPlugin } from './serverPluginAssets' | |||
| import { esbuildPlugin } from './serverPluginEsbuild' | |||
|
|
|||
| export { Resolver } | |||
| export { rewriteImports } from './serverPluginModuleRewrite' | |||
| export { compileSFCStyle } from './serverPluginVue' | |||
There was a problem hiding this comment.
I'm writing a plugin to do SSR based on a route, for that I need to parse the SFC file and build a script similar to what vite does. But vite relies on the middleware and the request path to retrieve the cached files or to parse a new file.
Being able to access the internals would be really useful.
There was a problem hiding this comment.
For consistency's sake, I think we either expose all compileSFC* methods or we expose none of them. However, making them public means we can't treat them as internals and freely tweak arguments anymore. They are also assuming to be only used in the dev-server, so it may at some time expect a Koa context - which would make them unusable elsewhere. I think for now it's safer to just copy-paste the logic in your plugin until it's more stable.
There was a problem hiding this comment.
Agreed, in my case I only need the Style, the others I basically copied the logic over.
Is the rewriteImports good to expose?
There was a problem hiding this comment.
Yeah, rewriteImports is probably safe, although I'd consider it semi-internal for now. You should be prepared if it breaks ;)
This reverts commit 2984b92.
Exposing
moduleRewriteandcompileSFCStylefor plugin creators