You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I been using this pattern for unplugin-vue-components for a while and I think it turns out a flexible and straightforward solution to support various component libraries without the changes need to be done on the author side. For example, some components might use JSX to build up the library, or uses all named exports on the top-level module, or imports styles separately. Additionally, the resolver opens more possibility to integrate on-demand usages, for example unplugin-icons which the icons are served virtually via module name. This would also be great if we could join the force from the Vite side to provide a uniformed resolver solution and made it easier for ppl adopting to more libraries at ease.
The text was updated successfully, but these errors were encountered:
Ideally, we should make PR to expose <lib>/nuxt module (like this) for proper nuxt integration with each of those libraries for taking advantage of all nuxt and hook possibilities and easier/consistent installation without import in nuxt.config. (*)
But seems a good idea to have compatibility with vite format. Basically, we shall extend ComponentsDir interface and detect/support a new format in the scanner to generate necessary entries.
(*) Other than integration possibilities, one major difference is that nuxt components mainly work with SFCs and require component libraries to expose them rather than a single bundle. This allows smart bundling with minimum transpile and dynamic injection of styles only when needed rather than global.
Similar approach to https://github.com/antfu/unplugin-vue-components#importing-from-ui-libraries
I been using this pattern for
unplugin-vue-components
for a while and I think it turns out a flexible and straightforward solution to support various component libraries without the changes need to be done on the author side. For example, some components might use JSX to build up the library, or uses all named exports on the top-level module, or imports styles separately. Additionally, the resolver opens more possibility to integrate on-demand usages, for exampleunplugin-icons
which the icons are served virtually via module name. This would also be great if we could join the force from the Vite side to provide a uniformed resolver solution and made it easier for ppl adopting to more libraries at ease.The text was updated successfully, but these errors were encountered: