Closed yyx990803 closed 6 years ago
For meteor, I would just need the component definition JS and the style (not sure how to manage pre-processors though - currently, it's a set of individual atmosphere packages that exposes a global to the .vue processor). I already made a HMR system that works in Meteor and since it's quite specific, I agree it should be left to the implementation outside of the component compiler.
For nativescript-vue we would need multiple template
and script
blocks (style
already supports multiple blocks). I have opened a PR in the Vue repository to add support for this: https://github.com/vuejs/vue/pull/7264
Another thing that we should consider is allowing changing the template-compiler
for a given block, for example if we have a <template web />
block, we would like to use the official vue-template-compiler
package, but for <template native />
we would like to use our own fork which includes some custom compiler modules specific to nativescript-vue.
I have moved all open tasks to the board.
I would be actively working on these tasks from this Friday. If anyone is picking something, please convert the task to issue and assign it to yourself. If you don't access then ping me, I'll do it for you.
The only open issue from this list is #36, tracked separately.
Prior design thread: #28
Thanks to the great work by @znck we now have a good start to iterate on. I did a quick review of the current codebase and here's a list of things I think we should work on next:
Feature Sync with Latest
vue-loader
[x] functional template support (https://github.com/vuejs/vue-loader/commit/c8a016aa3a351233ee9dc609d3c690864a3978e4, https://github.com/vuejs/vue-loader/commit/585b70c262f6bb32f5bb7e0172d6c77a641a3838, https://github.com/vuejs/vue-loader/commit/c7b53769c9810fee05a6b3037a6cb3ce3484643f)
[x] optional cache busting when generating source maps for blocks (https://github.com/vuejs/vue-loader/commit/1123b12c8a917459127afc6118a132bc9fa9c834)
[x] update
gen-id
implementation: https://github.com/vuejs/vue-loader/blob/master/lib/loader.js#L89[x] template compiler
transformToRequire
support wildcard (https://github.com/vuejs/vue-loader/commit/c58945483fd97ee0049653c910a065f55d16138f)[ ] named exports support (https://github.com/vuejs/vue-loader/commit/2e2aa2bcc8d593e8b37de4ab17ffbfe63fb41983)
[ ] esModule default export support in custom blocks (https://github.com/vuejs/vue-loader/commit/7459a87651ed5591bb97e315a40beaf64024ed30)
[ ] Scoped CSS transform bug fixes
[ ] use
prettier
instead ofjs_beautify
when formatting generated render function intemplate-compiler
To avoid having to maintain both side in parallel, I'll temporarily limit new features in
vue-loader
until we refactor it to use this package internally.Questions still open to Discussion
Current implementation seems to be assuming a module bundler environment, but technically this package should not be limited to that. (discussion in #33)
Should hot-reload be handled in here? Currently the hot-reload logic is quite specific to webpack, which should be the responsibility of
vue-loader
.How to distribute the runtime (
normalizeComponent
and style injection code)? I think this is tricky since it involves how the bundler can locate the packages, and in some cases the runtime may need to be directly inlined (related to #33).We might need to rethink how
assemble
works altogether. Rough idea: the baseassemble
function should assume much less and try to allow the user to decide how to handle styles, hot-reload and the normalization./cc @znck @eddyerburgh