[SOLVED] Vue.js is not working on Hosted Test

I am now trying to develop Twitch Extension using Vue.js.
My Twitch Extension, developed as Vue.js in the Local Test state, seems to work fine for me.
However, after switching to the Hosted Test state, Vue.js on my Twitch Extension will delete the root element itself and stop running.

I can not understand this result.

Is it impossible to use Vue.js as a Twitch Extension?
Or, is there another way to configure Vue.js for use with Twitch Extension?

You can download the test project from the link below.


This project is an initialized project with vue-cli,
Created with the following settings.

? Project name test-project
? Project description A Vue.js project
? Author
? Vue build standalone
? Install vue-router? Yes
? Use ESLint to lint your code? Yes
? Pick an ESLint preset Airbnb
? Setup unit tests with Karma + Mocha? No
? Setup e2e tests with Nightwatch? No

I also added twitch-ext.min.js file to index.html and assetsPublicPath from config / index.js to ‘./’ (relative path) . That’s all.

The tested nodejs version is v6.11.3, and yarn version is 1.0.0.

Your file.io link doesn’t work.

Did you include vue.js in your upload.

Most CDN’s will NOT work, so you MUST include libraries such as vue and jQuery (for example) in your upload to Twitch

I’ve modified the download link to a Google Drive link.

The project created with vue-cli used the results built with webpack.
Therefore, Vue.js is uploaded with the CDN, it seemed to be loaded properly.

In the project, I built it with the “yarn build” command, and I compressed it and uploaded it.

Assuming that this zip is a copy of the zip you uploaded, all your files are in a folder. (Which I don’t think it is)

They need to be at the root of the zip file

See this answer [SOLVED] 404, The specified key does not exist

Installing yarn to build and take a look…

Ok the build completed. I can’t see anything obviously wrong.

Check the console for errors of CSP problems.

I do see a number of EVALs in the code.

I know you can use vue as some other live extensions are.

I had to modify the webpack build to get mine running - not sure if that’s your issue, here’s my first commit to some boilerplate I started, I’ll update it with more new stuff and the EBS later in the week. It needs a readme etc still - but just PM me if you are still having trouble and I can take a look tonight.

I’m having a similar problem, in that using Vue locally worked fine, but during hosted mode, nothing works.

I see this error message in the console

“Refused to execute inline script because it violates the following Content Security Policy directive: “script-src ‘self’ https://0ms0a4rmjh6b7beixaqndrefsz1dfy.ext-twitch.tv https://extension-files.twitch.tv”. Either the ‘unsafe-inline’ keyword, a hash (‘sha256-y39vCFYw/BwWj881TjtfNsUChIKFjCrwIrdHdEdBvQQ=’), or a nonce (‘nonce-…’) is required to enable inline execution.”

You can see this error on my viewer.html page: viewer.html

Here is my zip file

I’ve verified that my assets were uploaded correctly, as i’m able to view the js/css files on the Twitch cdn.


The problem had nothing to do with the content security policy. It was an issue with the routing. During development, the routes take the form of localhost:8080/viewer.html.
Therefore my defined vue-routes would look like

                path: '/viewer.html',
                component: Viewer

The twitch dev dashboards tells you that during Hosted testing, the base URI will be


and the path for viewer.html would be viewer.html, same for config and live config. Therefore the routes would look like


I assumed that my routes would still work, because /viewer.html would match


However while trying to debug the problem, i noticed that the routes were actually of the form


Note the extra path segments in /0.0.1/eaabd8a1316d963ee6d712a843827d75/, which caused my routes to not match. My current fix is to declare the route as

                path: */viewer.html',
                component: Viewer

which matches any route that ends with viewer.html. After i did that, my extension started working.

Was i wrong to assume that the hosted test routes would be


The dev dashboard seems to imply that.

1 Like

I’m sure there was a note in the docs about all files needing to be local (as apposed to absolute) to the .html file but I can’t find it.

But this is why we have hosted test.

Either way, my first two extensions used local URL’s anyway and my third extension I’ve built a better local test that similulates the pathing/more deeper folder structure

I checked the repository mentioned by @bteamgaming yesterday, and I am correcting the following two things and confirmed that my project works in Hosted Test.

  1. Delete the line containing 'vue$': 'vue/dist/vue.esm.js' in the /build/webpack.base.conf.js file
  1. Use render instead of template and components in /src/main.js file

Thank you!

Thanks for updating it - I’m continuing to build it up slowly - Didn’t have any issues with the hosted stuff before. I’ll check it again, and update with changes if it needs it :]

Has anyone actually managed to get a standard Vue/Webpack extension like the one above approved? At the moment mine is setup with a single point of entry at index.html, with Vue-Router handling which component to load. Works great in all aspects, even deploying on the hosted test.

Unfortunately the approval gets denied because of the single point of entry, index.html, rather than having viewer.html, config.html, live_config.html. There may be other issues but it seems like the reviewers find one issue and hit deny.

The alternative is running everything with it’s own .html file and then including Vue with inbuilt templates without a build process. Unfortunately this won’t work on the hosted test as templates are compiled with Eval and the Content Security Policy blocks it. The workaround to this is to compile .vue template files down to render functions before deploy but it doesn’t look like there is an easy way to do this without using Webpack/Browserify.

I’ve been having trouble getting approved because they consider Webpack’s output to be obfuscated code. I know it’s possible because the Streamlabs extension is Webpack Vue. Or maybe it’s because Streamlabs was one of the first 20 extensions and they got preferential treatment, who knows.

It’s easy to create multiple html files that use the same bundled app thru webpack. I can link you the config if you want.

That’d be great if you could link that config. At the moment I’m just copying index.html 3 times for viewer, config and live_config (lol).

However now I’m getting the same review response, stating that Webpack’s output is obfuscated code. From looking at Streamlabs’ JS it doesn’t look like they’re doing anything special. Looks like they’re still using Webpack with configs to compile Vue templates down to render functions just like normal. The Destiny overlay uses a build process that outputs similar JS as well that looks just as unreadable. Same thing with the Amazon extension.

This entire process is extremely frustrating. There is absolutely zero communication options and on a good day you’ll get a full sentence of feedback from the review process.

You can find the config files in my github: https://github.com/guanzo/vote-to-play/tree/master/client

It’s a slight modification of the vue-cli webpack config. I found wherever index.html was being referenced, and added the other 3 required files. The main change was to add 3 additional HtmlWebpackPlugin objects to the webpack.dev.conf.js and webpack.prod.conf.js files. This will create 4 html files with the same vue app.

I also modified the config/index.js file to include the 3 additional files.

I sent an email to Streamlabs inquiring about their webpack config, but haven’t received a response yet.

I totally agree about the communication. I expect it to improve in the future as this process is brand new. There will be growing pains.

Thanks for the config link!

I’m going to do some playing around with trying to separate the Webpack output which should hopefully help. I’m not entirely certain its possible to the degree that the manual review process demands but we will see. I’ll post here if I get anything going.

Did putting a star before “/” end up working for anyone else? I have something that works in testing, and I’m happy with it, but these hosted restrictions are making me rethink whether or not I want to bother. I am running the server in .Net Core and the frontend with Vue through the vue-router. The lack of helpful documentation, helpful examples, or even reasonable error messages either from the dashboard when trying to load, or when the file is uploaded is making me question whether or not this is worth the effort.