Saw this question but renaming to jQuery doesn't help.
I'm trying to get some basic unit-testing in Webstorm to work. Even without the tests it's not finding things defined in other files.
I have this config file:
server: http://localhost:9876
load:
- libs/jquery-1.9.0.min.js
- src/jquery.combine/jquery.combine.js
But it get this error when running the tests:
error loading file: /test/src/jquery.combine/jquery.combine.js:2: Uncaught TypeError: Cannot set property 'union' of undefined
The path's are a bit different, but clicking it show's the right file.
jquery.combine.js looks like this:
(function($) {
$.union = function () {
// ...
};
}(jQuery));
Why is it not detecting jQuery? It includes it correctly because if I misspell the path it complains about missing file instead.
I was able to solve this with the help of JetBrains. Somehow this solves itself if you add a jsTestDriver adapter for QUnit. WebStorm comes bundled with this one.
My updated jsTestDriver.conf looks like this:
load:
- libs/qunit-jstd-adapter/equiv.js
- libs/qunit-jstd-adapter/QUnitAdapter.js
- libs/jquery/jquery.js
- src/*.js
test:
- test/*.js
I'm pasting the instructions I got from JetBrains (with slight modification) which helped me solve the issue:
1) delete jquery.combine/libs/qunit/qunit.js - doing so will make symbols 'test' and 'module' unresolved,
2) open jquery.combine/test/difference.tests.js and position test cursor on any 'test' function call, wait alittle and you'll see the suggestion:
"Add QUnit JsTestDriver adapter? Alt+Enter"
Invoking this quick fix will open a dialog, where you should specify a directory where "QUnit JsTestDriver Adapter" files will be added.
3) As equiv.js and QUnitAdapter.js files are located inside your project, load them in jsTestDriver.conf
4) Now right-click jsTestDriver.conf and select run (JsTestDriver server should be up and have a captured browser).
Related
I'm using Vite combined with React and Typescript.
When I run vite dev the live version of the website runs perfectly, not even errors on the console.
When I run vite build and then vite preview all I get to see is a white page and the
TypeError: can't convert undefined to object
error in the console.
I cannot trace the problem in my code because the error happens after the build/minimization, but just to be sure, I added safety checks in the instances where I call Object.keys().
This is the segment of the code where the error starts:
Object.keys(pd).forEach(function (e) {
if (pd[e] === 0)
Xd.prototype["on" + e] = function () {
this.scope.emit(e);
};
else if (pd[e] === 1)
Xd.prototype["on" + e] = function (t) {
this.scope.emit(e, t);
};
});
Edit:
I was checking the minimized code and right before the long block of code where the bug is, I saw a MuiTouchRipple. I'm using the MaterialUI library, is it possible that the library is causing this problem?
I tried to update from version 5.4.2 to 5.6.3, but after the build it still crashes.
I managed to fix it.
Posting the debug steps for the newbies like me.
Debug
1. Disable minimization
This allows you to see the original code, it's still in a bundled form, so you still cannot identify the exact file where the problem is, but at least you know something more. (in my specific case, since I'm using vite I had to change a variable in the config file, see https://vitejs.dev/config/#build-minify).
2. Change typescript compiler options
In my case the target and module were set to ESNext, trying to change it to ES6 or to commonjs helped to have a better searchable code.
(see https://www.tsmean.com/articles/learn-typescript/typescript-module-compiler-option/)
3. Search the code that causes the error
When I tried to search the code in vscode it did not appear. That's a good sign, at least my code was not causing the problem!
But at the same time: what now?
The solution I found is to either disable vscode excluded folders from the search (by default vscode does not search in node_modules), or to use grep -r in the project folder.
I found the latter to be faster and more efficient.
Solution
In my specific case the problem was an old library that hasn't been updated in years (https://www.npmjs.com/package/react-html-parser). Once I removed it everything started working.
I had similar problem, and for me this was caused by "target": "es5" in tsconfig.json.
After changing to esnext, problem is gone.
https://esbuild.github.io/content-types/#es5
I had a similar problem. For me it was the build.lib.formats setting in vite.config.ts, that I needed to remove.
I have the following configuration setup in WebStorm:
When I click debug, it launches Chrome fine and navigates to the page, but my breakpoints never get hit. It's connected somehow though because I see all of the console.log() output in WebStorm.
I'm trying to navigate to the URL specified in the screenshot and have breakpoints in main.js get hit, but it doesn't work as expected (see: at all). I'm not exactly sure what I'm missing. I've tried setting a remote URL for the specific main.js file in the Remote URLs section, but that didn't help either.
For reference I run the application via bra run and npm run watch.
Quick Update
So I've been able to actually get a breakpoint to hit, but it's in a different file (in a different path):
../public/app/core/routes/dashboard_loaders.ts allows me to stop at breakpoints, but ../public/dashboards doesn't.
When I navigate to http://localhost:3000/dashboard/script/main.js?orgId=1, it hits the route:
.when('/dashboard/:type/:slug', {
templateUrl: 'public/app/partials/dashboard.html',
controller : 'LoadDashboardCtrl',
reloadOnSearch: false,
pageClass: 'page-dashboard',
})
Which ultimately does load the file ../public/dashboards/multi.js -- but no breakpoints are hit.
Further Updates
It looks like the script is served via the following command (in ../public/app/features/dashboard/dashboardLoaderSrv.js):
/*jshint -W054 */
var script_func = new Function('ARGS','kbn','dateMath','_','moment','window','document','$','jQuery', 'services', result.data);
var script_result = script_func($routeParams, kbn, dateMath, _ , moment, window, document, $, $, services);
Where $routeParams are type:script and slug:main.js - If I step into this function, I get an anonymous(?) file that's identical to my actual main.js file, but the name is like 43550 instead of main.js -- I think this is boiling down to a fundamental lack of knowledge in how JavaScript handles something on my part. :)
Edit: I found this issue for using webstorm with grafana (second edit) looks like this is you.
I think what he linked solves it with declaring a sourceUrl then your file isn't "anonymous" or rather dynamic.
//# sourceURL=filename.js
I.E
//# sourceURL=main.js
Reference How to debug dynamically loaded JavaScript (with jQuery) in the browser's debugger itself?
Here is the documentation and video on debugging in webstorm to make sure everything is setup properly. (I.E My default setting were to debug my index file instead of my project). Make sure you have their Chrome extension or Firefox Extension
General JS Debugging in Webstorm
Debugging for Chrome in Webstorm
Debugging for Firefox in Webstorm
Debugging Node.JS in Webstorm
I need your help/guidance about one problem I have for the last two days.
The sonar-javascript plugin is not able to get the results of my Javascript UnitTests. I am generating unit tests and lcov results using JSTestDriver. The lcov results are working and are correctly shown in SonarQube. I also have to say that I am using Windows. Here is the error I have:
Test result will not be saved for test class "UnitTests.controlesTest", because SonarQube associated resource has not been found using file name: UnitTests\controlesTest.js"
The error is very similar to this one: Importing javascript XML JUnit tests to sonar using jstestdriver fails. However, this error seems to be fixed in the last SNAPSHOT (2.8). The file I am trying to access is stored in UnitTests/controlesTest.js. I tried to go into the sonar-javascript source, and find a way to correct this issue (at least, try to understand it). I ended up in the file JsTestDriverSensor.java in the function getTestFileRelativePathToBaseDir. I found that this line is not able to get my file (UnitTests\controles.js). Actually, fileIterator does not contain any InputFile.
Iterator<InputFile> fileIterator = fileSystem.inputFiles(predicate).iterator();
So I tried different predicates to understand why my file is not found. At the end, I found that the following predicate fileSystem.predicates().hasType(InputFile.Type.TEST) is the reason why this file is not found. A quick fix is to change:
- 108 testFilePredicate,
+ 108 mainFilePredicate,
I must be doing something wrong, maybe someone has an idea ?
The "sonar.tests" property has to be set in the sonar-project.properties (or in newer version SonarQube.Analysis.xml). This allows the sonar-javascript plugin to find the javascript test files.
We have some QUnit javascript tests running in Visual Studio using the Chutzpah test adapter. Everything was working fine until we changed our api (the one being tested by the js files) recently, and added some validations over the UserAgent http header. When I tried to update the tests to change/mock the user agent I realized it was not directly possible even by overriding the default browser property.
After a few days of scavenging, I finally found what exactly is happening. Chutzpah is creating a phantomjs page object for the test files to run on. This is being done on a base javascript file (chutzpahRunner.js) located at the Chutzpah adapter installation path. These are the last lines on the file, that effectively start the tests:
...
// Allows local files to make ajax calls to remote urls
page.settings.localToRemoteUrlAccessEnabled = true; //(default false)
// Stops all security (for example you can access content in other domain IFrames)
page.settings.webSecurityEnabled = false; //(default true)
page.open(testFile, pageOpenHandler);
...
Phatomjs supports changing the user agent header by specifying it in the page settings object. If I edit this chutzpahRunner.js file in my machine, and manually set the user agent there, like this:
page.settings.userAgent = "MyCustomUserAgent";
My tests start to work again. The problem is that this is not in the project itself, and thus cannot be shared with the rest of the team.
Is it possible to change the properties of the phantomjs objects created by Chutzpah to run the tests? I'd like to either change them from inside my own tests, or from another script file I could embed on the pipeline.
Without a code change in Chutzpah it is not possible to set those properties on the PhantomJS object. Please file an issue at https://github.com/mmanela/chutzpah asking for this functionality and then fork/patch Chutzpah to add it (or wait for a developer on the project to hopefully get to this).
Update:
I pushed a fix for this issue. Once this is released you can use the following in a Chutzpah.json file:
{
"userAgent": "myUserAgent"
}
Trying to add tests support into my project. Attached JsTestDriver with coverage plugin.
Dummy tests are working correctly, but when I load up all my source files I'm getting application crashed with the following:
[java] **line 109:12 no viable alternative at input 'formFound'**
[java] Exception in thread "main" com.google.jstestdriver.coverage.CodeInstrumentor$InstrumentationException: error instrumenting /path/discover.js
[java] at com.google.jstestdriver.coverage.CodeInstrumentor.instrument(CodeInstrumentor.java:74)
[java] at com.google.jstestdriver.coverage.CoverageInstrumentingProcessor.process(CoverageInstrumentingProcessor.java:62)
This line of code looks like:
let formFound = tryToFindLoginForm();
I changed that definition into
var formFound = tryToFindLoginForm();
After that JSTD will pass over that string but will die on next let statement. Is there any way to workaround this, to tell JSTD the version of javascript used in code or something?
It'll be a very big issue to rewrite entire code into version without lets.
Thanks for help in advance.