Next steps

[yyx990803]

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

• functional template support (vuejs/vue-loader@c8a016a, vuejs/vue-loader@585b70c, vuejs/vue-loader@c7b5376)

• optional cache busting when generating source maps for blocks (vuejs/vue-loader@1123b12)

• update gen-id implementation: https://github.com/vuejs/vue-loader/blob/master/lib/loader.js#L89

• template compiler transformToRequire support wildcard (vuejs/vue-loader@c589454)

  • bug fix for srcset (vuejs/vue-loader@ddcea20)

• named exports support (vuejs/vue-loader@2e2aa2b)

• esModule default export support in custom blocks (vuejs/vue-loader@7459a87)

• Scoped CSS transform bug fixes

  • vuejs/vue-loader@c303312
  • vuejs/vue-loader@47c3317
  • vuejs/vue-loader@bcd54d2
  • vuejs/vue-loader@6d3c5b2

• use prettier instead of js_beautify when formatting generated render function in template-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 Assemble in line function #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 Assemble in line function #33).

We might need to rethink how assemble works altogether. Rough idea: the base assemble 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

[Akryum]

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.

[rigor789]

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: vuejs/vue#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.

[znck]

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.

[znck]

The only open issue from this list is #36, tracked separately.