Errors -"TypeError: Cannot read property 'rtl' of undefined"

[dsvanidze]

Hi @vatson,

Please take a look at this issue https://github.com/team-innovation/vue-sfc-rollup/issues/44. I describe there a problem of vuetify during bundling without your plugin. This is a repository, where I created a sample of my problem. I installed today your rollup-plugin-vuetify and there come a lot of other errors, one of them is "TypeError: Cannot read property 'rtl' of undefined".

Do you have an idea how to solve these errors and bundle SFC so that I can use it in other project without any problems?

[vatson]

Hey @dsvanidze,

TL;DR: remove "node_modules" from your linked package (I guess it's sfc-rollup-vuetify) and re-build your application that uses this package.

I really wanted to think that your problem may relate to some new problem. But your problem is too old and lies beyond this plugin and vue-sfc-rollup. They work correctly.

Your problem is the combination of "npm link", the nature of nodejs module loading and the vue intolerance to multiple instances from different places.

Short introduction how import in nodejs works. If your script has some kind of library import, then nodejs initially looks in the local node_modules folder, if local node_modules doesn't contain required dependency then nodejs goes to the folder above to find node_modules and your imported dependency there.

In your case, your sfc-rollup-vuetify points to vuetify/lib so it's resolved as sfc-rollup-vuetify/node_modules/vuetify/lib. In turn, the vuetify/lib points to the vue module, and since sfc-rollup-vuetify/node_modules/vuetify/lib does not have its own "node_modules", then it looks for dependencies in the folder one level higher. At the end, it's find vue from node_modules/sfc-rollup-vuetify/node_modules/vue and loads the code from that module. The instance from "node_modules/sfc-rollup-vuetify/node_modules/vue" !== "node_modules/vue". For some reason this causes a conflict and throws the errors you see.

I really wanted to fully understand this, but so far I have no answers why vue behaves this way and why we see errors in unexpected places that do not tell us the real cause of the problem.

For my part, I can say that I also encountered your problem of using "npm link" + external library with vuetify. But unfortunately today I do not have a working solution.

[vatson]

@dsvanidze Do I understand correctly that this issue can be closed? 😁

[dsvanidze]

@vatson Thank you so much! If you are in Germany, I would like to buy you a beer. It was so easy to remove node_modules folder in the project of my library and Voilà, everything works!!! It took me so many hours.

I would very appreciate if you find a solution, so that I do not need to remove node_modules everytime, when I work with npm link.

Other question: I would like to use vee-validate for validation. I changed rollup.config.js and entry.ts. You can see changes in this commit https://github.com/dsvanidze/vue-sfc-rollup/commit/3dc423216e070c4539374de8adfa31469853b379. If I import it in another Vue application, it works great, but my questions if it is the correct way, how I changed my rollup and entry.ts files? Is it the right way to use Vue.use() in entry.ts if my components library have to use other plugins and components?

[vatson]

@dsvanidze

I'm not a big fan of idea "the usage of 3rd party plugins inside small standalone components that are distributed as npm packages" but it can work ok if:

• used plugins don't add anything to vue.prototype;
• these plugins don't register components globally or if they do then there is strategy of resolving name collisions.

You have to be careful with your case. But this does not apply to the items listed above. vee-validate doesn't pollute vue.prototype (phew), even global registration of ValidationProvider by your library will not break anything if someone registers ValidationProvider at the application level one more time. Moreover, there is useless to give an alias for ValidationProvider or use it locally via importing in each your component. And it's waste of time due to design of vee-validate. Under the hood, vee-validate use a singleton pattern for its rule set. It means that you have shared rules through all parts of applications: app level, 3rd party components, etc.

I found this in documentation for the previous 2.x version (for some reasons this information lacks for 3.x):

Using any of the extend either on the class or on an instance will extend all validators with the new validation rule. Extending a new rule that has the same name as an existing rule will silently overwrite

or you can find in the code of current version https://github.com/logaretm/vee-validate/blob/master/src/extend.ts#L26

Therefore, I suggest using very specific/unique names for validation rules to avoid potential conflicts. Thus, your rules will not overwrite existing or be rewritten themselves, depending where your library will be included in the application.

The issue can be closed now? 😁