I joined a group building a product with Node, Webpack, TypeScript and Express/Feathers. Other developers know what they are doing, but I have only used JavaScript on a client until now and have literally only a few hours of Node under my belt. Trying to figure out how to go about debugging. Specifically, my first task is to fix some failing API tests.
Tests are executed with:
$npm run testserver
My package has:
"scripts": {
....
"testserver": "webpack --config webpack.servertest.config.js && NODE_ENV=test mocha dist/serverTests.js",
....
},
The routine is to compile typescript into ES6 then babel to ES5 compatible with Node.
I tried doing:
$node-debug dist/serverTests.js
When this node-debug invocation runs, the results are not the same as with npm. Please share your experience.
Thank you
Based on your setup, I can recommend you to try Visual Studio Code, OS text editor/ide based on Electron as well as Atom editor.
To solve your issue you can use two vscode features:
Debugging - link on docs how to debug in vscode
Tasks - task management, for instance to look into webpack config which is started with some args and etc
Firstly, let's try simple solution that may be appropriate in your case (tasks file doesn't need):
Add to the end of testserver --debug-brk it's used for debug in node.js, brk - it simply stops execution on the first line.
"testserver": "webpack --config webpack.servertest.config.js && NODE_ENV=test mocha dist/serverTests.js --debug-brk",
Now when you npm run testserver, mocha starts in debug mode and in console you will see something like Debugger listen on port 5858
Second step, in vscode you need to add some props (port 5858) to launch.json - read section Debugging in docs that I mention above:
{
"version": "0.1.0",
"configurations": [
{
"name": "Attach", // or e.g. "Mocha Debug"
"type": "node",
"request": "attach",
"port": 5858
}
]
}
And that's it. Go in debug mode in vscode, put breakpoint in a test file, choose in dropdown 'Attach' or 'Mocha Debug' and start debugging(F5)
p.s. Also VS code has first-class TypeScript support that may be helpful for you.
Related
I'm working on a massive project and since last week I updated mocha, Now we are getting warning:
DeprecationWarning: Configuration via mocha.opts is DEPRECATED and
will be removed from a future version of Mocha. Use RC files or
package.json instead.
I want to migrate the options to package.json but there is no good migration guide. all posts on GitHub with similar questions are all answered "see the docs". But the docs doesn't show how to transfer one option from mocha.opts to package.json, there is no information on how it should be formatted. Only thing I can find is that the "spec" property is the pattern for files to run. Nothing else seems implicit to me.
Our mocha.opts file:
--reporter dot
--require test/mocha.main
--recursive src/**/*.test.js
--grep #slow --invert
My attempt which doesn't work:
"mocha": {
"reporter": "dot",
"require": "test/mocha.main",
"spec": "src/**/*.test.js",
"grep": "#slow --invert"
},
Please explain how I should format this configuration block in order to achieve samme behaviour as when using the options from the above mocha.opts
I too had some difficulties finding the exact solution for migrating to new standards and could finally resolve those. I hope I'm not too late and I can still help you.
So first thing, you would need a new config file to replace mocha.opts. Mocha now offers quite some variations of file formats which can be used for it. You can find these here in their GIT. I took .mocharc.json and will be using it for further examples. Although adding it didn't change anything just the way it shows no effect for you too.
The catch was to point mocha test script to this config file in package.json. Provide --config flag in the test script in the scripts section in your package.json like below.
"scripts": {
"test": "mocha --config=test/.mocharc.json --node-env=test --exit",
"start": "node server"
}
Now you can update your configs in the .mocharc.json file and they should reflect correctly. Below is an example of it.
{
"diff": true,
"extension": ["js"],
"package": "../package.json",
"reporter": "spec",
"slow": 1500,
"timeout": 20000,
"recursive": true,
"file": ["test/utils/helpers.js", "test/utils/authorizer.js"],
"ui": "bdd",
"watch-files": ["lib/**/*.js", "test/**/*.js"],
"watch-ignore": ["lib/vendor"]
}
I'm using file property to define which files should go first as they need to be executed first. They will be executed in the order you provide them in the file array. Another property you can play around is slow whose value defines whether mocha consider the time taken to execute any test case as slow or not.
Check out this link to see the new format of the options file for mocha:
https://github.com/mochajs/mocha/blob/master/example/config/.mocharc.yml
Basically you need a .mocharc.yml, or .mocharc.json, (there are a couple more formats) to set the mocha configurations. I came to this POST hoping to find an answer too. Hope this is helpful for you!
I ended up getting the package.json working by using an array instead of the string literals you did.
ex:
"mocha": {
"require": ["tsconfig/register"]
}
Might be worth a try!
Seems like mocha won't check the package.json for config by default so you need to pass --package package.json.
/* This example illustrates how to configure mocha globally
*1. add the 'mocharch.json' to link mocha to the 'package.json' like so:
*/
{
"package": "./package.json"
}
/* 2. in the 'package.json' add: */
"mocha": {
"recursive": "true"
}
The answer by Rathore is great, but I just wanted to point out that if you just add the .mocharc.json file to your base directory, you don't need to specify "--config=test/.mocharc.json" in your package.json, it just finds it automatically.
you can create .mocharc.json in project root folder.
{
"spec": "src/tests/**/*.ts",
"require": "ts-node/register"
}
in package.json add mocha property.
"mocha": {
"spec": ["src/tests/**/*.ts"],
"require": ["ts-node/register"]
}
js project change file name.
I have a JS web app that has a client and server bundle, both built using webpack's node api.
Running my project in dev mode goes through these steps:
Run two webpack builds, resulting in two output files.
Server bundle is output to dist/server/index.js
Spawn child node process using the dist/server/index.js path
Watch folder for changes. On change, kill the old child process and re-run steps 1-3
I want to add node server debugging using vscode.
So far, I've added the following flags during step 3, when I launch a new child process.
['--inspect=9222', '--no-lazy', '--inspect-brk']
My launch.json file in vscode looks like this
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to dev server",
"type": "node",
"request": "attach",
"protocol": "inspector",
"address": "localhost",
"port": 9222,
"restart": true,
"trace": true,
"stopOnEntry": true
}
]
}
When I start the server and run the debugger, things mostly work.
However, I'd love to fix the following two things:
Even with "stopOnEntry": true, the debugger will not pick up any breakpoints, unless I include "--inspect-brk" when launching my child process. This is annoying, because if I'm not running the debugger, the process will hang and will not continue execution. With this flag included, when I run the debugger, the built dist/server/index.js file will open in my editor with a breakpoint on line 1. If I hit continue, all future debugging works.
I'm generating sourcemaps using webpack's "inline-source-map" option. This puts the "original source" in the built file. However, it's the source after babel transformation, making debugging the code a little annoying. E.g. _myFunction.default instead of myFunction. Does vscode have a way to correctly map the built .js file to the pre-built source code in my project? I saw the remoteRoot and localRoot options, but could not get them to work (and am unsure if these are the correct options).
Thanks!
Update VS Code 1.47+:
With the new JavaScript debugger in VS Code 1.47 and later versions, child processes are automatically debugged in Node.js - just set breakpoints where needed.
Example launch.json (with TypeScript source to illustrate the sourcemap approach):
{
"type": "pwa-node",
"request": "launch",
"name": "Launch Program",
"skipFiles": ["<node_internals>/**"],
"program": "${workspaceFolder}/main.ts", // use .ts source
"outFiles": ["${workspaceFolder}/dist/**/*.js"], // search here for sourcemaps
}
Example main.ts:
const { spawn } = require("child_process");
const args = [path.resolve("./child.js")];
const proc = spawn(process.execPath, args, { stdio: "inherit" });
See this post for an explanation of pwa-node.
VS Code debug options
program: specifies main source file to be debugged. You can directly reference the .ts source file - VS Code will search the workspace for sourcemaps or consult outFiles.
outFiles: tell VS Code to explicitely search for sourcemaps in these glob locations.
sourceMaps: if VS code shall look for sourcemaps; defaults to true, so no need to set.
stopOnEntry: breaks immediately when program launches - same, as a breakpoint on first line. 1
nolazy: ensures that breakpoints are validated before the code is run and don't "jump". Per default, VS Code sets this flag automatically, so it can be left out.
remoteRoot / localRoot: are for remote debugging and are not directly related to generating sourcemaps (see OP question).
autoAttachChildProcesses: was used to automatically attach to child processed launched in debug mode; no need to set it with new debugger.
Node debug options
--inspect: starts the program in debug mode without waiting for the debugger to be attached.
--inspect-brk: same as --inspect, but waits for the debugger to attach before starting.
You can set one of these to enable debug mode for a program started on the command-line. Note: VS Code now can also auto-attach from integrated terminal without these flags given.
Generate sourcemaps with Webpack
For webpack, you can generate sourcemaps with inline-source-map or source-map 2.
// inside webpack.config.js
devtool: "inline-source-map",
If babel-loader is used, sourcemaps should be considered and merged automatically by webpack with above config entry. For TypeScript, see the Webpack docs.
(Old) Debug child legacy solution
If that does not work in older versions, pass a conditional DEBUG environmental variable for --inspect/--inspect-brk together with autoAttachChildProcesses:
const runner = spawn(process.execPath,
[...(process.env.DEBUG === "true" ? ["--inspect-brk"] : []), ...args],
);
// inside launch.json configuration
"env": {
"DEBUG": "true"
},
1 Despite this developer comment, stopOnEnty has not been propagated to child processes for me - even with autoAttachChildProcesses and child processed started with --inspect.
2 These options provide best compatibility from my experience.
I'm using VS Code for TypeScript/JavaScript development. When I open a file it will check that file for errors. The problem is if I'm refactoring (like I move some shared code to a new location or change a name) it won't show me the errors this caused until I open the file with the problem. ...so if I want to do extensive refactoring I have to open every file just to make it scan the file for errors.
How can I make VS Code scan the whole project for errors without having to open each file one by one manually?
VS Code (v1.44) has an experimental feature, that allows project wide error reporting in TS. Try it out:
// put this line in settings.json
"typescript.tsserver.experimental.enableProjectDiagnostics": true
Figured it out. Note this answer is specific to TypeScript, which is what I am using. Here it is:
Make sure typescript is installed globally (I just had mine installed locally apparently):
npm install -g typescript
Then in VS Code press Shift+Ctrl+B. If you don't have a task runner set up it will ask what you want. I selected typescript and the tasks.json file will look like this:
{
"version": "0.1.0",
"command": "tsc",
"isShellCommand": true,
"args": ["-p", "."],
"showOutput": "silent",
"problemMatcher": "$tsc"
}
Then pressing Shift+Ctrl+B (or Shift+Command+B in macOS) will check the entire project for problems and they will be reported in your "problems" panel.
If you don't want to install TypeScript globally, you can do the following:
Install TypeScript locally on the project, that is yarn add --dev typescript or npm install --save-dev typescript.
Add a check-types run script to ./package.json. --noEmit means that the compiler will won't generate any JavaScript files.
{
"scripts": {
"check-types": "tsc --noEmit"
}
}
Let VSCode know about the run script in /.vscode/tasks.json.
{
"version": "2.0.0",
"tasks": [
{
"type": "npm",
"script": "check-types",
"problemMatcher": [
"$tsc"
]
}
]
}
To run the tasks hit the F1 key and select 'Run Task', and then 'npm: check-types'.
If you add the following lines to the task, pressing Ctrl+B will run it.
"group": {
"kind": "build",
"isDefault": true
}
For the most recent version of tasks.json this is the correct json, following deprecations in version 1.14. Create this as /.vscode/tasks.json
{
"version": "2.0.0",
"command": "tsc",
"type": "shell",
"args": [
"-p",
"."
],
"presentation": {
"reveal": "silent"
},
"problemMatcher": "$tsc"
}
Once you have open your project in vs code, open the vs code terminal and run:
node_modules/.bin/tsc --noEmit
Go to View menu > Extensions and make sure the Microsoft VS Code ESLint extension is installed.
In Settings, search for "ESLint > Lint Task: Enable", and enable that setting (docs).
In the Terminal menu, choose Run Task… > eslint: lint whole folder.
UPDATE.
My answer below does not answer the original question, but if you're like me and have found this thread searching for how to turn on // #ts-check project-wide in VSCode so that you don't need to add // #ts-check to every file then my answer below is what you need. I have searched and searched and kept getting this thread as my top result so hopefully this helps others as well
I'm on vscode version 1.52.1 and the answer is so simple and right on the vscode website:
https://code.visualstudio.com/docs/nodejs/working-with-javascript#_type-checking-javascript
scroll down to the "Using jsconfig or tsconfig" section
Add a jsconfig.json in your project root and add "checkJs": true
{
"compilerOptions": {
"checkJs": true
},
"exclude": ["node_modules", "**/node_modules/*"]
}
You might need to restart vscode once you add it in
None of the other solutions worked fully for me. Here's a tasks.json that does, working with vscode 1.67+. On Linux etc. set command to tsc, on Windows be sure to run tsc.cmd as tsc alone will attempt to run the bash script and produce the following error:
The terminal process failed to launch: A native exception occurred during launch (Cannot create process, error code: 193)
"revealProblems": "always" in the presentation section shows the Problems panel on completion.
{
"version": "2.0.0",
"tasks": [
{
"label": "tsc: error check project",
"command": "tsc.cmd",
"args": [
"-p",
".",
"--noEmit"
],
"isBackground": false,
"problemMatcher": "$tsc",
"group": {
"kind": "build",
"isDefault": true
},
"presentation": {
"revealProblems": "always",
}
}
]
}
Edit: Since updating to 1.52.0 this no longer works. It will instead replace the current project files with what you selected...
===
I've tried every solution I can find and I think it's safe to say the answer is: You can't*
The best I've found is still technically opening each file manually, but at least it's not one-by-one:
You can't drag/drop a directory but you can select multiple files (including directories) and drag/drop. The directories will be ignored and any files you had selected will be opened in tabs.
Next, you need to give each tab focus so it triggers eslint to run. (Holding down the next tab keyboard shortcut works.)
This is terrible and I beg someone to prove me wrong.
*I haven't found a way that works as well as opening files manually. Each method -- experimental vscode feature and tsc task -- has its own set of drawbacks. The vscode feature is clearly the solution but without a way to ignore node_modules, etc. it's too painful to use.
I use foreverjs to start my services. Also I use nodejs v5 with nvm. Running on mac.
Everything working fine yesterday, but today (after npm update) I suddenly have an errors like /node_modules/my-service-one/node_modules/my-service-onewhen I'm try to npm start.
The project structure is:
.
|-package.json
|-services.json
|+-node_modules
|-forever
|-my-service-one
|-my-service-two
Config for foreverjs (services.json):
[
{
"append": true,
"uid": "my-service-one",
"script": "index.js",
"sourceDir": "node_modules/my-service-one"
},
{
"append": true,
"uid": "my-service-two",
"script": "index.js",
"sourceDir": "node_modules/my-service-two"
}
]
And I launch it with npm start(package.json):
...
"scripts": {
"start": "node_modules/forever/bin/forever start services.json",
}
...
But when I try to make npm start, I have an error:
Error: Cannot find module '/Users/my_user/project_name/node_modules/my-service-one/node_modules/my-service-one/index.js'
WTF is this: /node_modules/my-service-one/node_modules/my-service-one? Why?
It should use /node_modules/my-service-one/index.js. So why?
UPD: What I've already try(without result):
rm -rf node_modules;
Restart;
Use node v4, v5, v6;
npm cache clean;
Find other node_modules in wrong places inside project;
Google it;
This is bad question perhaps, but I'm really didn't know why it's happens. Thanks.
Have you tried to launch this modules with forever from command line?
This path issue looks like a bug for me, I think the obvious duct-tape type fix is use absolute path in services.json instead of relative. It will look terrible but it should work.
But I think it's better to install forever globally (with -g key) and then use a simple shell script to start your services with forever (two lines with something forever start /Users/my_user/project_name/node_modules/my-service-one/index.js) - this way works fine for me.
And also it's quite easy to start this script at the boot-up, or even write a script to start and stop your modules as a service.
UPD: This also may helps: sourceDir: './'
I'm writing some mocha tests that load code that have paths like this:
import MyStore from "stores/MyStore"
This works fine in the web browser because we are using the webpack-dev-server which in turn reads this entry from webpack.config.js: config.resolve.root: [path.resolve(__dirname, "./app")] so it knows to find ./app/stores/MyStore.
This path does not work when running it from mocha --compilers js:babel/register. I'm trying to locate a package or configuration that I may use for this. It would save us from having to change may code references and of course keep our imports more portable.
Not sure if it matters, we use iojs. If this really can't be done it would be fine just to update the paths. Thank you...
How about including your app directory in $NODE_PATH:
env NODE_PATH=$NODE_PATH:$PWD/app mocha ...
Here's a cross-platform method. First install cross-env:
npm install cross-env --save-dev
then in your package.json:
"scripts": {
...
"test": "cross-env NODE_PATH=./app mocha ..."
}
In windows, I had to do this:
set NODE_PATH=%CD%/app&& mocha...
for some reason, adding a space after 'app' would cause it not to work