Open prodrammer opened 6 years ago
@ArtemGovorov any updates on this ? I think many of us are waiting for this feature ! Thanks for the awesome work !
Hi @ArtemGovorov,
just wondering, should we expect any updates this year here, or?
Thanks, Ruslan
Hi @ArtemGovorov,
I appreciate that devs only have so much time, but I would really appreciate some feedback as to where you're at with this.
Points of interest:
Thanks for your hard work, I really like using Quokka as my JS scratchpad when writing my Vue Components.
Many thanks, Ryan
Hi All,
Thanks for the recent posts on this issue. @RCVarley, I've provided some feedback on the questions that you asked:
What are the technical challenges involved with supporting Vue SFCs?
For Quokka to properly executing a Vue SFC, a runtime environment for Vue is required. Right now, this is not a concept that exists in Quokka. Quokka is limited to a providing a single runtime environment, node.js that simply runs your TypeScript/JavaScript code, expecting you to provide a program/entry point to execute from. Quokka would need to somehow be aware of various ways that the Vue SFC can be hosted/processed (e.g. using Nuxt, vue-loader for Webpack) and process the appropriate configuration options. The various ways that Vue can be configured makes it technically challenging to add support in a turn-key way; we don't want to add a feature to Quokka that requires extension configuration. This level of configuration (including support for Vue) is however supported by our other product, Wallaby; if you're really looking for a solution to test your Vue SFCs, then check out Wallaby as it may provide what you're looking for.
In this thread, it was previously suggested to just enhance Quokka so that it executes the code that exists within script tags of the Vue SFCs, but this also doesn't seem to make sense to us. As per the Vue SFC spec, the script tag is expected to provide a default export without any entry-point to executing your code. While Quokka could run the code defined between script tags, the only item that would run is the export, e.g. there's no logic in your script to call your exported data()
function or execute any other logic, which means that nothing would actually happen. Depending on your script tag and your Vue configuration, additional processing may also be required to transpile your code (e.g. TypeScript, Babel, etc.). You could mitigate this by editing the code in your script tag to provide an entry point for Quokka to run from. While perhaps not ideal, you could also edit your code to use Vue src imports and start Quokka on the external files instead of within the .vue
file.
Is this feature on your roadmap?
No, we do not have any immediate plans to provide support for Vue SFCs. We review open issues every 2 months, so will re-evaluate this issue in April 2020.
Are you waiting for anything specific before working on this feature?
No.
Would you consider supporting plugins, to enable the community to expand support?
Definitely. Quokka already provides an extensibility model that could be used to provide support. Support for a limited set of scenarios could be provided with a combination of a Quokka plugin (similar to jsdom-quokka-plugin) and a babel plugin to take the Vue source code and compile it to JavaScript code for Wallaby to execute. The babel plugin would need to include source maps so that Quokka can provide correct line indicators and output messages. We would also need to make some code changes to Quokka to support this (right now Quokka's babel compiler ignores .vue
files), but those changes would be relatively minor for us to implement and something that we could fit into our existing schedule.
If you are interested in working on a quokka plugin + babel plugin to expand support for Vue SFCs, we'd be happy to work with you, provide guidance, etc. Please email us at hello@wallabyjs.com if you wish to discuss further.
+1
+1
+1 for vue support
+1 for vue support
I currently have a vue project in typescript. Is it correct that quokka will not work with .ts files if I use ES6 imports of .vue files for example?
The quokka console gives some token errors, for example: { and <. If I removed some es6 imports it works correctly.
//index.ts
import SomeComponent from "SomeComponent.vue"
...
// some regular ts/js code . . .
@calvinchoy - Quokka is currently unable to parse/transform .vue
file imports. Quokka tries to run your files using node.js
whereas your .vue
files need some runtime transformations. This happens at build time in webpack with vue adding the vue-loader
module or when you're testing by the vue-jest
module.
Right now, there's no equivalent for us to do the same with Quokka when running in node.js
.
If your project has unit tests, you can use our other product, Wallaby.js to run your unit tests, which provides Quokka-like features in the context of running your unit tests. Wallaby performs other runtime transformations and provides a rich runtime environment (unlike simply running your Quokka scratch file in node.js
) which allows it to process your .vue
files.
Any updates here? :)
As far as we are aware, there is still no way to run a Vue single file component in node.js
. A couple of immediate roadblocks that we could see you might run into doing this are:
+1
+1
+1
+1
This would be really useful
As far as we are aware, there is still no way to run a Vue single file component in
node.js
. A couple of immediate roadblocks that we could see you might run into doing this are:
- Providing inputs to your SFC
- Interacting with the SFC after it has been created (unless it's a very simple render-only SFC)
- Loading dependencies
All of this makes sense, @smcenlly so I see why it's a challenge especially with the myriad of possible configurations out there.
Is it possible we could introduce it as a simpler implementation? Utilising an entry point and still using the same logic as Quokka on standard js/ts files you could have a soft requirement for supporting Vuejs that any Vue components you want to have Quokka support on require an explicit entry point in the same folder?
It might then be possible to associate the source mapping generated by the Vue-CLI serve watch system to react to it as a trigger point for when Quokka needs to update.
As for the interaction challenges I would happily give up the ability to debug parent interactions with the component to utilise Quokka based on default props/mocked data (though I also think I might be treading that line where Wallaby might fit better).
+- src
| +- components
| | +-test-button
| | | +-TestButton.vue
| | | +-TestButton.css
| | | +-index.js <- Mounts single component with mocked props for default case
| | +-test-checkbox
| | | +-TestCheckbox.vue
| | | +-TestCheckbox.css
| | | +-index.js <- Mounts single component with mocked props for default case
| +- index.js <- Mounts a selection of components
+-index.js <- Main app entry point compiling the app
@thopiddock - thanks for your thoughts. What you're describing sounds like an interesting concept but is not Quokka anymore... probably some hybrid-type product between Quokka and Wallaby. We had experimented with something similar to this for create-react-app
projects but shelved our effects after a while as the user experience required manual UI interaction and results were not intuitive.
I assume you had also read this previous message in the thread?
For Quokka to properly executing a Vue SFC, a runtime environment for Vue is required.
Depending on how much of Vue runtime you use, there could be a lot of work to facilitate running Vue SFC in node.js.
Also,
Quokka provides an extensibility model that could be used to provide support. Support for a limited set of scenarios could be provided with a combination of a Quokka plugin (similar to jsdom-quokka-plugin) and a babel plugin to take the Vue source code and compile it to JavaScript code for Wallaby to execute. The babel plugin would need to include source maps so that Quokka can provide correct line indicators and output messages. We would also need to make some code changes to Quokka to support this (right now Quokka's babel compiler ignores
.vue
files), but those changes would be relatively minor for us to implement and something that we could fit into our existing schedule.
If you are interested in working on a quokka plugin + babel plugin to expand support for Vue SFCs, we'd be happy to work with you, provide guidance, etc. Please email us at hello@wallabyjs.com if you wish to discuss further.
Will buy pro if it supports Vue.
Vue support would have been great! It's the only JavaScript I use, so this plugin is of no use to me now. Will check it out again when it is supported.
I wonder if the vue composition api could change the complexity of a vue integration.
Could a node instance create a run-time that handles the ref() reactivity piece? Could there be a mvp that didn't handle the lifecyle hooks or dependency injection?
Could a node instance create a run-time that handles the ref() reactivity piece?
Creating the runtime environment to run Vue files inside node.js is outside of our areas of expertise. If/when a library exists to do this, we are happy to evaluate creating an integration with it.
You may also like to check out one of our other products, Console Ninja, which can run your Vue code from your development environment. While it doesn't have the same functionality as Quokka, it may be more suitable for working with Vue files.
https://quokkajs.com/whatsnew/vsc-vue-svelte.html
Seems that Vue is now supported inside of VSC, are there plans for making this work in Jetbrains editors as well?
We’ve added the ability to quickly prototype inside Vue.js single file components and Svelte files to Quokka for IntelliJ which will allow you to validate code between script tags.
This is available in Quokka for IntelliJ v1.0.453
.
I currently use WallabyJS. It appears to work with
.vue
files just fine. Any chance quokka can support.vue
files?Thanks!
Visual Studio Code v1.23.0 OSX 10.13.4