This is not question, just answer:
Create run/debug configuration, type Node.js
Select your node interpreter
As node parameter insert your ava bin and parameter --verbose
For me it's: ./node_modules/.bin/ava --verbose
Select your working directory
Done, now you can debug
The magic is in --verbose, I have no idea why it works that way, but it does.
I have no idea why/how it works for you - configuration is definitely wrong.
With your configuration, --inspect-brk is passed to ava, not to Node.js, and thus treated as your application argument. You should have specified node_modules/.bin/ava as JavaScript file: in your Run configuration instead of specifying it as a Node parameter, to make sure that Node debug arguments are passed before the application main file. --verbose can be passed as application parameter.
See also https://github.com/avajs/ava/blob/master/docs/recipes/debugging-with-webstorm.md
Create a new node test runner with following configuration:
Node interpreter: whatever version of node that you are using that is compatible with your ava version
Working directory: ~/Documents/Work/projectRootDir
Javascript file: node_modules/ava/cli.js
Application parameters: -v outdir/testFile e.g. /dist/test/controllers/test.js
There you go, now you can run and debug AVA with the best javascript IDE instead of console logging!
I'm quite sure that vscode config will be quite similar
Related
Selenium server standalone jar version keeps updating and webdriver-manager update command picks latest jar. Every time selenium jar update I need to change seleniumServerJar in exports.config.
Is there any way to put some regex?
Like this :-
seleniumServerJar: "../node_modules/protractor/selenium/selenium-server-standalone-*.jar",
Short answer - No you cannot. As per the implementation of protractor config parser, the seleniumServerJar property accepts only a string as its value. Here's a link to its implementation. As you can see, until the typeof - seleniumServerJar's value is string, protractor will not resolve the path of the jar file. And if the value is a string that doesn't resolve to a particular path in your directory, then protractor will throw an error.
Edit: Protractor tests will run even if you don't provide path of seleniumServerJar as its an optional property that you can provide if you store the jar file in a different location other than the default location. Default location here is either path where protractor is installed or relative path of your config file. Which means whether you install protractor locally or globally selenium server jar protractor executes your scripts.
Hope it helps.
As the other answer mentions, if you simply remove seleniumServerJar from your config file, it will look for the jar file that is in protractor/selenium folder, which is where webdriver-manager update downloads to. Then you won't have to worry about bumping the version in your config file when you upgrade protractor since webdriver-manager gets the version number from protractor/config.json.
Relevant source documentation:
Priority
1) if directConnect is true, use that
2) if seleniumAddress is given, use that
3) if a Sauce Labs account is given, use that
4) if a seleniumServerJar is specified, use that
5) try to find the seleniumServerJar in protractor/selenium
I have a sample code and saved it to a file such as hello.ts
After installing nodejs on windows use below command for installing typescript
npm install -g typescript
How can I compile hello.ts with node.js directly?
When I install "TypeScript 1.6 in VS2015" and use tsc.exe don't have any problem but I want to use node.js instead of VS 2015 extension
Please guide me generate .js and .ds through Node.js
Run tsc in the command line, you'll have the help page. Compiling a script is easy, just tsc hello.ts in the folder containing your script, you'll get a hello.js file.
Please guide me generate .js and .ds through Node.js
You have two options:
Run tsc.js as a node script
Use typescript as an npm module
Run node tsc.js
This is the approach taken by some tools e.g grunt-ts. You basically just call spawn on the current process process.execPath passing in the other commands as args (-d).
One sample
Run TypeScript as a node module
If you are playing with the typescript compiler API highly recommend NTypeScript See the Readme for reasons.
The TypeScript compiler provides a simple function called transpile that you can use to get the expected output and then write it out to disk yourself.
PS: I have some docs on the TypeScript compiler internals here : https://basarat.gitbooks.io/typescript/content/docs/compiler/overview.html
My preferred way to get going is to use typescript-require.
this library basically adds nodejs support for typescript.
your index file should be a javascript file and it will look like this
require('typescript-require');
require('./src/main.ts');
and main.ts is a typescript file.
Here's a programatically way from TS/Node to run the equivalent of tsc from within a code itself (Note: this uses the TypeScript Compiler API):
https://gist.github.com/rnag/0d8fe2e72dc7b48743c13f9ca8837a4c
I'm using node-jasmine 2 beta4 and writing in coffeescript. I'm happily running tests in Intellij 13.1 having setup the following Run Configuration
Node interpreter: /usr/local/bin/node
Working Dir: [Project Directory]
Javascript File: node_modules/jasmine-node/bin/jasmine-node
Application Parameters: --coffee --verbose spec
I also have setup file watchers for all my coffeescript files and they are building correctly and put into a [Project Directory]/.build subdirectory
Great! But setting breakpoints when debugging is not working. The information sent back to Intellij seems to reference the javascript files given the line numbers I am seeing suggesting that sourcemaps are not being referenced correctly.
Can anyone help?
(Currently i make do by adding a debugger statement instead of intellij's breakpoints)
I think your Javascript file should be node_modules/jasmine-node/lib/jasmine-node/cli.js. The jasmine-node documentation recommends using the cli.js file when using node directly instead of NPM (look under Usage).
In my test directory, I have a file mocha.opts containing the following:
--harmony
--recursive
--growl
--reporter spec
--require should
When I run mocha, I get the following error:
/project/server/utilities/encryption.js:3
const
^^^^^
SyntaxError: Use of const in strict mode.
This is, of course, because my use of const requires ES6 Harmony. When I run mocha --harmony, my tests execute just fine. And the other entries in my mocha.opts file work as expected.
Does the mocha.opts file ignore the --harmony argument for some reason? Or am I doing it wrong? The Mocha docs don't elaborate and I haven't been able to find the answer here or anywhere else.
The asker asks:
When I run mocha --harmony, my tests execute just fine. [...]
Does the mocha.opts file ignore the --harmony argument for some reason?
Yes, mocha.opts ignores the --harmony argument. The --harmony option is not a Mocha option but a Node.js option. This is an option that must be passed to Node.js before it starts executing. However, mocha.opts is read after Node.js has started and so even if Mocha was able to understand the option, it would not be able to do anything about it.
But why does it work on the command line? Shouldn't it be the case that when I run mocha --harmony, Mocha has to first start before parsing the --harmony option? No, because mocha is script that starts the "real" Mocha. The shell script detects --harmony and makes sure it is passed to Node.js when it starts the "real" Mocha.
It's not support as something you can include in mocha.opts. You much add in to the command line when you call mocha. See this.
Grunt uses PhantomJS to run headless QUnit tests in a very interesting way (correct me if I'm wrong please). Since I just started experimenting with those tools I don't fully understand it and don't know how to configure nor how to extend it.
I manage to get all working on my machine but I would like to not use the $PATH system variable. Instead, I would like to provide the path to PhantomJS's executable file via a setting which I could easily change and port to other environments.
How can I achieve this?
I suppose there are many ways and I think the Qunit Task from Grunt might have an easy answer. Ideally it would be just a matter of defining the path on the grun.js file, something like this:
qunit: {
phantomjsPath: 'path/to/phantomjs',
files: ['test/**/*.html']
},
My environment is a MacOSX but I accept solutions for any kind of environments like Windows - my build server.
Thanks in advance.
UPDATE The version of Grunt I am using is v0.3.17. The next big version, v0.4.x, has many changes and some are not backwards compatible.
Well I think you finally migrated onto Grunt 0.4. And propably you got grunt-contrib-qunit plugin for running qunit tests under PhantomJS. Unfortunately you'll encountered the same issue - it's not possible to supply path to phantomjs executable. That's because grunt-contrib-qunit/grunt-contrib-phantomjs use phantomjs npm module which downloads PhantomJS on installation and hard-codes path to the executable in its js code. If you're experiencing such an issue then please check my blog post.
Unfortunately, grunt 0.3.x doesn't have a built-in option to specify a path to phantomjs -- it just executes phantomjs directly on the command line. Take a look at this helper function:
https://github.com/gruntjs/grunt/blob/master/tasks/qunit.js#L231
The situation seems to have changed in the has-yet-to-be-released grunt-0.4, however:
https://github.com/gruntjs/grunt-lib-phantomjs/blob/master/lib/phantomjs.js#L22
As you can see, the next version of grunt uses the npm module phantomjs which "exports a path string that contains the path to the phantomjs binary/executable.". Since the npm module phantomjs is installed locally by grunt, it seems like this would avoid you having to worry about setting the PATH variable or installing a conflicting version of phantomjs.
Anyway, I'd consider taking a look at grunt-0.4 if you're willing to live on the bleeding edge.
Otherwise, you can always fork the qunit task and modify the grunt-qunit task to look at your custom configuration variable.