What I'm using
VSCode
Quasar (Vue)
Typescript
Eslint/#typescript-eslint
Prettier / prettierhtml / Vetur
Current issue:
Until recently, injected script in the <template> of vue files (e.g. onSignIn in <div #click="onSignIn"> was checked against available variables/methods in the <script lang="ts"> part. This has now stopped working and I couldn't figure out what's the reason. Playing around with VSCode/Vetur/eslint settings wasn't successful either so far.
As the above hasn't worked earlier either but just since I started my latest project, I'm not sure what settings is responsible for that part anyway (Veturs' HTML > Validate > Scripts apparently is not enough) and my first question is, whether it works for you; the second, if you know exactly why/why not (?).
Setting vetur.experimental.templateInterpolationService: true did the trick.
I have the following code with a simple working Vue.js application. But the vue.js devtools is not responding. It was working well a few days ago, now it's not working anymore what could possibly be going wrong? when I go to https://chrome.google.com/webstore/detail/vuejs-devtools/nhdogjmejiglipccpnnnanhbledajbpd, it says it is already added.
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport"
content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<script src="https://unpkg.com/vue#2.1.6/dist/vue.js"></script>
<title>Document</title>
</head>
<body>
<div class="container">
<div id="application">
<input type="text" v-model="message">
<p>The value of the input is: {{ message }}</p>
</div>
</div>
<script>
let data = {
message: 'Hello World'
}
new Vue({
el: '#application',
data: data
})
</script>
</body>
</html>
One alternative is to set up a local web server, as the OP already stated.
The other - which IMHO is faster and less harassing - is letting the extension have access to file URLs, which is disabled by default.
Simply go to chrome://extensions and leave the "Allow access to file URLs" box checked for Vue.js devtools.
Sources:
https://github.com/vuejs/vue-devtools#common-problems-and-how-to-fix
I tried all of the ways presented in answers here, but none of them worked for me (neither for chrome nor for firefox).
Finally I found an answer: If you still have this problem, you can try to uninstall the current version of Vue extension and install beta version: https://v3-migration.vuejs.org/breaking-changes/introduction.html#devtools-extension
Remember to restart your browser afterwards.
UPDATE: 2021 May 30,
If you are using Vue 3, old dev tools versions won't work, so just use the new beta version.
https://chrome.google.com/webstore/detail/vuejs-devtools/ljjemllljcmogpfapbkkighbhhppjdbg
To solve this, simply go to chrome://extensions/, scroll down to the Vue.js devtools and enable the "Allow Access to file URLs" by clicking on its checkbox.
Source: https://github.com/vuejs/vue-devtools/issues/236
Had the same issue and solved it by adding
Vue.config.devtools = true;
after Vue.js import script, then take look at chrome devtools. You will see a tab called Vue to inspect your vue instance.
reference: https://v2.vuejs.org/v2/api/#devtools
I found out the answer, I was viewing a plain html file on my computer which was making the vue.js tool not load. I loaded up my local xampp server and ran the application from the local machine server url again and now vue.js devtools is working! :)
Also you can disable with Vue config:
https://v2.vuejs.org/v2/api/#devtools
in the extensions folder in chrome browser, under the details tab in vue devtools extension, check the box having allow access to file URLs,
this worked for me..
If you're using Vue 3 and experiencing this issue, try installing the beta version of the Vue Devtools. It may help until the stable version gets the major refactor.
I had the same issue & solved it by:
Installing this extension Vue Dev Tools Beta Chrome Extention
Reloading the chrome browser.
i had this problem, and i was expecting the vue-devtools to work by just including it. i had it console log the version
console.log("Vue Version " +Vue.version );
but this didnt work to actually load an instance of vue.
took me a few minutes, but once i actually created a vue instance, then it worked. this was the hello world example that made the devtools work :)
let data = {
message: 'Hello World'
}
new Vue({
el: '#application',
data: data
})
I solved the same problem.
But in my case Vue.js Chrome Devtools didn't detect Vue.js because in html file was <script src="https://unpkg.com/vue"/>
I replaced it to <script src="https://unpkg.com/vue"></script>
Now Chrome Devtools is detecting Vue.js perfectly.
Thanks for exapmle above.I use vue#2.4.4 and open my html by file://
In the case of Firefox, install the beta version of vue-devtools, which supports Vue 3.
If you have already turned on Allow Access to file URLs in chrome://extensions/ -> Vue Devtools and it still does not work, try reinstall the Vue Devtools, might work for you.
check if vuejs app is not embedded in an iframe such as in a storybook app.
the hack in such a case is to work outside the parent frame working directly on the url of your iframe and the vue devtools should work fine.
I'm using Vue in electron and I have the electron main "app" separated Vue's "app".
When in the the debugger console, typing Vue was giving the error Uncaught ReferenceError: Vue is not defined
Here was my fix
window.vue = new Vue({
components: {
App,
Login,
},
router,
store,
template: '<App/>',
}).$mount('#app');
The work-around was assigning window.Vue so the devtool could find it.
The same problem here, and I've solved it.
If you are developing in the localhost environment and using Chrome Dev Tools then you need to give permission for the Vue.js extension to access the local files on your computer.
Config your Vue.js tool in Chrome extensions
Search for "Vue.js devtools"
Click on details
Check the "Allow access to file URLs" checkbox
In my case I just had compiled for production npm run prod - which was the issue. As I ran in dev npm run dev, it started recognizing Vue.
I'm hoping someone with some experience in Breeze/Durandal 2 on .NET 4.0 will be able to assist me with this error, as I'm pretty new to the mix.
I've been working on a Durandal 2/KO/Require SPA project that lately has been compiling fine and running on my IIS7. I need this app to be compatible with IE8, so I imported the shim and sham js libs as such:
<!-- ECMAScript 5 compatibility shims for IE8 -->
<!--[if lt IE 9]>
<script src="lib/ie8/html5shiv.min.js"></script>
<script src="lib/ie8/respond.js"></script>
<script src="lib/ie8/es5-shim.min.js"></script>
<script src="lib/ie8/es5-sham.min.js"></script>
<![endif]-->
<script src="lib/jquery/jquery-1.9.1.min.js"></script>
<script src="lib/knockout/knockout-3.1.0.js"></script>
<script src="/Scripts/q.min.js"></script>
<script src="/Scripts/breeze.debug.js"></script>
<script src="lib/bootstrap/js/bootstrap.js"></script>
I also need to be able to access data from a DB so I tried adding BreezeJS to the mix. According to Breeze's documentation, in order for this to work I had to remake the project in VS as ASP.NET MVC4 Project using the Empty Template. After that I imported the Breeze files using NuGet:
Install-Package Breeze.WebApi
Then I added in my pre-existing views, controllers, libraries, css, etc. to the newly created project. Now when I compile using IE8 I get the following error. This error does not show up for Firefox or Chrome:
Unhandled exception at line 125, column 13 in
http://localhost:64185/lib/durandal/js/composition.js
(Edited for readability)
SourceMap D:\localdev\TestMVC4\TestMVC4\lib\ie8\es5-shim.map read failed:
Could not find file 'D:\localdev\TestMVC4\TestMVC4\lib\ie8\es5-shim.map'.
SourceMap D:\localdev\TestMVC4\TestMVC4\lib\ie8\es5-sham.map read failed:
Could not find file 'D:\localdev\TestMVC4\TestMVC4\lib\ie8\es5-sham.map'.
Unhandled exception at line 125, column 13 in http://localhost:64185/lib/durandal/js/composition.js
0x800a138f - Microsoft JScript runtime error: 'route' is null or not an object
I thought this might be a compatibility issue with JQuery so I attempted different versions there. I've made sure that my DocType is set to:
<!DOCTYPE html>
and that I have the following meta tag:
<meta http-equiv="X-UA-Compatible" content="IE=edge, chrome=1" />
However I doubt either of those would cause issues with IE8 and Durandal. Has anyone else experienced a similar issue to mine? Am I experiencing this error because I haven't configured something on the MVC4 side?
Any advice would be greatly appreciated.
Thank you
After further digging into the Durandal composition.js I found that the skipActivation parameter in the "tryActivate" function was undefined, which resulted in the error. I'm pretty sure this problem is a result of IE8 support from Durandal, so I went ahead and scrapped IE8 and I am now developing for IE9 and up.
This isn't a fix, but I've had enough headaches with this and I will be moving on ...
I'm using Dojo 1.9.1 AMD with WebSphere 8 portlets and can't figure out how to continue to leverage the WebSphere mechanism for getting/setting user's portlet preferences. Prior to moving from pre-AMD Dojo (1.6) to Dojo 1.9.1 AMD, I was including at the top of some JSP files these lines:
<%# taglib uri="http://www.ibm.com/xmlns/prod/websphere/portal/v6.1/portlet-client-model"
prefix="portlet-client-model" %> <portlet:defineObjects/>
<portlet-client-model:init>
<portlet-client-model:require module="ibm.portal.xml.*"/>
<portlet-client-model:require module="ibm.portal.portlet.*"/>
</portlet-client-model:init>
which get converted/generated into these lines at run-time:
<script> if(typeof dojo=='undefined') {
document.writeln("<scr"+"ipt src='/wps/portal_dojo/v1.4.3/dojo/dojo.js' ></scr"+"ipt>");
} </script>
<script>dojo.require('ibm.portal.xml.xpath'); dojo.require('ibm.portal.xml.xslt');</script>
<script>dojo.require('ibm.portal.portlet.portlet');</script>
<script>if(typeof(ibmPortalConfig) == "undefined") {ibmPortalConfig = {contentHandlerURI: "/wps/mycontenthandler/urs/!ut/p/digest!q8eCn6qc7fl2VjdmXXlayA/nm/oid:wps.portal.root"};} else if(!ibmPortalConfig["contentHandlerURI"]) {ibmPortalConfig["contentHandlerURI"] = "/wps/mycontenthandler/urs/!ut/p/digest!q8eCn6qc7fl2VjdmXXlayA/nm/oid:wps.portal.root";} </script><div id='com.ibm.wps.web2.portlet.root.Z7_HHGGGIO0JGPN00AI72U5E530O2' style='display: none;'>/wps/mycontenthandler/urs/!ut/p/digest!q8eCn6qc7fl2VjdmXXlayA/pm/oid:--portletwindowid--#oid:Z6_HHGGGIO0JGPN00AI72U5E530G4</div>
<div id='com.ibm.wps.web2.portlet.preferences.Z7_HHGGGIO0JGPN00AI72U5E530O2' style='display: none;' pageid='Z6_HHGGGIO0JGPN00AI72U5E530G4' configid='Z3_HHGGGIO0JGPN00AI72U5E53085' editdefaultsid='Z5_HHGGGIO0JGPN00AI72U5E530O6'
></div>
<div id='com.ibm.wps.web2.portlet.user.Z7_HHGGGIO0JGPN00AI72U5E530O2' style='display: none;'>/wps/mycontenthandler/urs/!ut/p/digest!q8eCn6qc7fl2VjdmXXlayA/um/secure/currentuser/profile?expandRefs=true</div>
which then allowed me to use javascript for getting and setting user portlet preferences. When I try using this same technique with Dojo 1.9.1 AMD, the same code that is generated above causes a javascript error complaining that the "dojo.require" is not a function.
With the improved Dojo AMD, I no longer have any calls to "dojo.require" like I used to, so I haven't encountered this issue, but these WebSphere custom tags automatically generate "dojo.require" calls that are now failing.
Do I need to try to mix the old pre-AMD inclusion of dojo.js with the preferred AMD inclusion calls? Has anyone encountered this issue yet?
Any help is appreciated. Thanks.
Your main problem is that you're using an old taglib. If I look at the URL I see that you're using a v6.1 taglib, which uses Dojo 1.4.3 and that is obviously outdated. Try to replace the taglib with:
<%# taglib
uri="http://www.ibm.com/xmlns/prod/websphere/portal/v8.0/portlet-client-model"
prefix="portlet-client-model" %>
I suppose that should generate some more appropriate code, compatible with the latest releases. You will probably have to update some libraries on your classpath as well.
Also, if you're using WebSphere Portal 8, then only Dojo 1.7 is supported officially, so make sure you're not using different versions here. WebSphere Portal 8.5 supports Dojo 1.9 (uses 1.9.3 to be exactly), but from your question it was not clear if you're using v8 or v8.5.
If you want to change the Dojo configuration and set async: false, that's possible, but you will have to set it before dojo.js is loaded. That means you will have to edit theme.html and the localized themes (for example theme_en.html) to add the following content above the co:head dynamic content spot:
<script type="text/javascript">
dojoConfig = {
async: false
};
</script>
<link rel="dynamic-content" href="co:head">
Be careful though, if you set it, you might break something, I don't know if IBM has their own configuration that includes custom packages or not, but if they do and you're overriding that configuration, then it might lead to errors.
I think i have already read all the related questions here, but sadly i couldn't find an answer yet.
My problem is, locally everything runs fine without errors but when i deploy my website to my server, i'm getting there the following error:
The following sections have been defined but have not been rendered for the layout page >"~/Views/Shared/_Layout.cshtml": "styles"
I'm using Asp.Net MVC 4 with the Razor engine and .Net 4.5.
In _Layout.cshtml i have the following block defined:
<head>
....
#Styles.Render("~/Content/Css")
#Scripts.Render("~/bundles/modernizr")
#RenderSection("styles", required: false)
</head>
And in Index.cshtml the following block:
#section styles{
<link rel="stylesheet" href=... />
#Scripts.Render("~/bundles/js/somejs")
}
This is driving me crazy. If this error would also occur on my development machine, i could debug it. But it only happens on my server, locally everything runs fine.
Even other projects with similar code pieces run fine on my server.
Maybe someone has any hints for me?
I suspect that the contents of the _Layout.cshtml or Index.cshtml on your server is not what you think it is. Maybe the deployed version is different than what you have locally. Deployment went wrong?