As highlighted by talks at VueConf by @octref and @masahirotanaka, vetur already has the infrastructure in place to allow the addition of intellisense for component libraries like element-ui (@ElemeFE) and OnsenUI. Having rich intellisense for components is immensely useful, especially for libraries with a lot of components and complex props.
ProposalI think it would be very useful to expand those capabilities, so that in the future intellisense for project-specific components or libraries can be added without any modifications to vetur itself. In a brief conversation about this with @octref we arrived at one option being the introduction of a vetur-specific config file similar to a .babelrc or .eslintrc. Such a config file could then be used to define components in a JSON format similar to the current support for OnsenUI (link pending) and element (#234).
This would enable authors of bigger projects to add intellisense for external libraries or their own custom components, greatly helping the team as complexity grows.
Caveats and further improvementsOne shortcoming of having a simple config file in the style of ESLint or similar tools is that while this would solve the issue for custom components, it would not work very well for external libraries. Manually copypasting component definitions from multiple external libraries together would be quite tedious.
Another issue might be name collisions for cases where components are not globally registered. Maybe it is possible for the vue language server to infer registered components inside a .vue file to resolve ambiguities? It might also be perfectly valid to just ignore this. Prefixing components is helpful for other reasons anyways, already done by most libraries, and prevents collisions from happening in the first place.
Regarding how to provide or bundle the definitions: one solution might be the introduction of a standard component description format for providing intellisense, similar in concept to typescript definition files. These could be bundled with libraries and also be created inside the project for local components. Another solution (especially for preventing the overhead of having to keep the intellisense documentation in sync with component changes) would be a way to have something similar to docstrings inside the components themselves. Using that, or a combination of parsing/reflection on the components (#145), would result in a living documentation that is not outdated as soon as it is published.
A hybrid approach that combines a bit of both might be to provide a tool that does the parsing/processing and generates the documentation. The generated files could then be bundled with the libraries, and the generator could be integrated into the build pipelines of library authors.
Of course, the latter options are at the very least technically challenging and might not be feasible at all, so a simple initial solution would be preferred. Nonetheless, i think a discussion about those edge cases and possible ways to deal with them could help arrive at a more sophisticated and robust solution.
Points of discussionAlso pinging @HerringtonDarkholme as the apparent champion of the element-ui integration.
rafegoldberg, tanathos and lukas-trrafegoldberg
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4