VSCode not auto-detecting grunt file - azure

I have VSCode 0.8 installed on windows 10, open to a folder. The grunt file at the root of this folder is named gruntfile.js (I also tried grunt.js). The grunt tasks work from the node cli but are not discovered inside VSCode.
I've tried ctrl+shift+p, then 'run task deploy-to-azure' where the task name in the grunt file is deploy-to-azure.
How is the grunt file auto-detected? Is there a way to turn on error reporting in VSCode or a log file I could review to see what is happening? Or perhaps an enumeration of all grunt, gulp, jake tasks?

Agreed I did this in .vscode/tasks.json and it all works OK for me. I did have to reboot because I lost grunt during the upgrade somehow.
// A task runner configuration.
{
"version": "0.1.0",
"command": "grunt",
"isShellCommand": true,
"tasks": [
{
"taskName": "build",
// Make this the default build command.
"isBuildCommand": true,
// Show the output window only if unrecognized errors occur.
"showOutput": "silent"
// Use the standard less compilation problem matcher.
/* "problemMatcher": "$lessCompile" */
},
{
"taskName": "test",
// Make this the default build command.
"isBuildCommand": false,
// Show the output window only if unrecognized errors occur.
"showOutput": "always"
// Use the standard less compilation problem matcher.
/* "problemMatcher": "$lessCompile" */
},
{
"taskName": "localhost",
// Make this the default build command.
"isBuildCommand": false,
// Show the output window only if unrecognized errors occur.
"showOutput": "always"
// Use the standard less compilation problem matcher.
/* "problemMatcher": "$lessCompile" */
}
]
}

Related

Jest moduleNameMapper and NPM package exports

I am developing fullstack NPM packages with multiple entrypoints (namely client, server and sometimes tests), using the exports property of package.json.
I also use a small hack to make TS work with exports until it's officially supported (see this Stack Overflow post, this hackish solution and this ticket).
The package.json ends up looking like this:
{
"name": "#vulcanjs/graphql",
"version": "0.4.7",
"main": "./dist/index.js",
"files": [
"dist/"
],
"exports": {
".": "./dist/index.js",
"./server": "./dist/server/index.js",
"./testing": "./dist/testing.js"
},
"types": "./dist/index.d.ts",
"typesVersions": {
"*": {
"server": [
"./dist/server/index.d.ts"
],
"testing": [
"./dist/testing.d.ts"
]
}
},
"description": "Vulcan graphQL schema generator",
...
You can then import using either #vulcanjs/graphql for shared code, and #vulcanjs/graphql/server for Node.js-only code.
It works perfect in my Next.js app. However, it seems to break Jest moduleNameMapper.
First, I had this:
moduleNameMapper: {
"#vulcanjs/(.*)": [
"<rootDir>/node_modules/#vulcanjs/$1",
],
},
The error is:
Configuration error:
Could not locate module #vulcanjs/graphql/server mapped as:
[
"/code/vulcan-next/node_modules/#vulcanjs/graphql/server",
].
The problem is that it tries to find a package named #vulcanjs/graphql/server: yet "server" is not a different package, it's an entrypoint of #vulcanjs/graphql.
I've also tried this:
moduleNameMapper: {
"#vulcanjs/(.*)/(.*)": [
"<rootDir>/node_modules/#vulcanjs/$1",
],
},
With this config, #vulcanjs/graphql/server is mapped to #vulcanjs/graphql. The problem is that now, server code is not found. I've checked and the problem is that this solution totally removes the /server: so #vulcanjs/graphql/server points to the main entrypoints instead of the server entrypoint.
Finally I did try to remove the moduleNameMapper, but then #vulcanjs/graphql/server package is not found by Jest. Note that I need the mapper for a use case I did not demonstrate here, so getting rid of it is possible but not the best solution.
The bug can be reproduced by installing the framework: https://github.com/VulcanJS/vulcan-next. You can clone, yarn install, unskip the test in src/models/tests/sampleModel.server.test.ts and run yarn run test:unit sampleModel. It will show the error.
Any idea how I could fix this?

Unbound breakpoints in Docker node.js TypeScript application

There are a lot of questions on this topic, and I have tried many of the solutions that worked for others, but the solution seems to depend on several things such as the version of VS Code and the recipe used.
This is my VS Code Help>About info:
Version: 1.60.2 (user setup)
Commit: 7f6ab5485bbc008386c4386d08766667e155244e
Date: 2021-09-22T12:00:31.514Z
Electron: 13.1.8
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.17763
The OS is Windows 10.
The Docker plugin is installed.
I have Docker Desktop 2.3.0.3 installed.
The application is written in TypeScript with inversify IOC.
I am using the launch.json and tasks.json files in src/.vscode.
The Docker container is built with the contents of the workspacefolder in /app. It is running locally, using the VS Code Docker plugin.
launch.json:
{
"configurations": [
{
"name": "Docker Node.js Launch",
"type": "docker",
"request": "launch",
"port": 9229,
"protocol": "inspector",
"preLaunchTask": "docker-run: debug",
"localRoot": "${workspaceFolder}/",
"platform": "node",
"remoteRoot": "/app/",
"sourceMaps": true,
}
]
}
tasks.json:
{
"version": "2.0.0",
"tasks": [
{
"type": "docker-build",
"label": "docker-build",
"platform": "node",
"dockerBuild": {
"dockerfile": "${workspaceFolder}/Dockerfile",
"context": "${workspaceFolder}",
"pull": true
}
},
{
"type": "docker-run",
"label": "docker-run: release",
"dependsOn": [
"docker-build"
],
"platform": "node"
},
{
"type": "docker-run",
"label": "docker-run: debug",
"dependsOn": [
"docker-build"
],
"dockerRun": {
"env": {
"DEBUG": "*",
"NODE_ENV": "development",
},
"command": "node --inspect-brk=0.0.0.0 dist/index.js",
"envFiles": [".env"],
},
"node": {
"enableDebugging": true,
"inspectPort": 9229
}
}
]
}
tsconfig.json:
{
"compilerOptions": {
"target": "es2018",
"module": "commonjs",
"noImplicitAny": true,
"strictNullChecks": true,
"removeComments": true,
"preserveConstEnums": true,
"sourceMap": true,
"outDir": "./dist/",
"experimentalDecorators": true,
"emitDecoratorMetadata": true,
"typeRoots": [ "./types", "./node_modules/#types"],
"resolveJsonModule": true
},
"include": ["src/**/*"],
"exclude": ["node_modules", "src/**/*.test.ts", "types", "**/tests/*.ts"]
}
When I initiate debug (select the Docker Node.js Launch option and hit F5), the docker builds and starts. The application stops on the first line of dist/index.js, but all my breakpoints (which are all in classes) show as unbound and the debugger does not stop on any of them. The application runs normally otherwise.
I assume that the breakpoints are unbound because VS Code can not map the running code back to the breakpoints in the source. But I have tried opening the files inside the container and setting breakpoints there, and that doesn't work either.
What do I have to do to make breakpoints work?
I had a similar issue today and was finally able to solve it. I will provide my findings here in the hope it might be helpful to you too.
1. Use trace
By setting trace: true in the launch.json configuration, you will get a lot of more details in your logs.
You can read how to make use of that here: NodeJs Debugging in Visual Studio Code
When starting the debugger config with trace: true, you will get a log entry in your debug console in the likes of
Verbose logs are written to:
/somepath/vscode-debugadapter-xxxxxx.json.gz
You can take this logfile and analyze it here in this interesting online tool by Microsoft: vscode-pwa-analyzer (Whole Project on Github)
There's a whole lot of logs in there. Probably best if you just try it out and see if you see anything helpful in there.
2. check your sourcemaps
For me it really helped to look at one of my sourcemap files. Go to your build / dist or whatever name you use for your build directory and look for a .map File.
If you open it, you should see something along the lines of
{"version":3,"file":"somefile.js","sourceRoot":"","sources":["../../../src/somedir/somefile.ts"] ... }
Make sure that the sources path is correct. Otherwise there might be something off with your tsconfig File.
3. check the outFiles config
This seemed to be necessary for me to configure to make it work. Add all the paths as glob patterns that contain compiled Javascript Files.
"outFiles": ["${workspaceFolder}/dist/**.js"],
4. sourceMapPathOverrides
There might also be an issue with the Source Map Paths. You can see if adding this snippet here helps:
"sourceMapPathOverrides": {
"webpack:///./*": "${workspaceRoot}/*",
},
5. check the program config
For me, adding the program config property finally did the trick.
If you don't know which one that might be, in my case it helped looking at what my Chrome used as the entry File.
Go to chrome://inspect in your Chrome Browser while your application is started and check what you see there.
In this example the entry File would be the server.js, which led me to configure the source of that file as the program, (with the local path) like so:
"program": "${workspaceFolder}/src/server.ts"
Conclusion
Your setup is probably different from mine and I still don't understand all the settings 100% to be honest. But maybe one of these things helps you get closer to find a solution. Let me know if it helped, and good luck.

How Do I Debug An Angular 7 Library in Visual Code

Is it possible to use Visual Studio Code Debugger to debug an Angular Library that has been linked using npm link? Very specifically I am wondering if I can link the debugger to my library's TypeScript Code (not the built js code).
My debugger works fine for the application I am running through the VS Code, however my linked library breakpoints are never hit.
From the research I have done I believe I understand why this is happening (the app using the library does not have the source, it only has the compiled code within node_modules) however I cannot figure out or find any details on how to debug.
Here is an overview of what I have done:
Angular 7 library built into dist folder.
I ran npm link within the dist folder
I ran npm link #my/test-lib in my application, the library shows up in node_modules and the application is able to use it just fine
in angular.json: sourceMap is true, preserveSystemlinks is true, aot is false, vendorSourceMap is true
tsconfig.json sourceMap is true, enableResourceInlining is true
vscode launch.json has runtimeArgs set to --preserve-symlinks and --preserve-symlinks-main
I'm posting just to provide a clearer example to #SyncingDisks solution:
You actually don't need the full path, ${workspaceFolder} would do the job also:
"webpack:///ng://angular-reporting/lib/*": "${workspaceFolder}/projects/angular-reporting/src/lib/*"
which would fit in launch.json as follows:
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome",
"url": "http://localhost:4200",
"webRoot": "${workspaceFolder}",
"sourceMapPathOverrides": {
"webpack:///ng://angular-reporting/lib/*": "${workspaceFolder}/projects/angular-reporting/src/lib/*"
},
}
Don't forget to add --vendorSourceMap to ng serve which would become:
ng serve --vendorSourceMap
Update:
for Angular 7 and higher update the "angular.json" file instead of adding "--vendorSourceMap" to "ng serve":
"serve": {
"builder": "#angular-devkit/build-angular:dev-server",
"options": {
"sourceMap": {
"scripts": true,
"styles": true,
"vendor": true
},
...
}
}
Fine tune your launch.json based on the sourceMapPathOverrides. Excerpt from mine:
"sourceMapPathOverrides": {
"webpack:///ng://<<your-awesome-lib>>/lib/*": "C:/<<full path to your library wrapper app>>/projects/<<your-awesome-lib>>/src/lib/*"
},

visual studio code node.js debugger fails to attach on standard launch

I tried to use the simple node.js example visualstudio code provides, but unfortunately when node is being started from visual studio code (on OS X) the node gets started with some arbitrary debug-brk, but debugger attachment fails.
When I run the node app manually with --debug-brk = 5858 and then use the attach I can debug my app. Anyone faced the same problem?
P.S I got mono installed from the mono project page .pkg
Here is my launch.js:
{
"version": "0.1.0",
// List of configurations. Add new configurations or edit existing ones.
// ONLY "node" and "mono" are supported, change "type" to switch.
"configurations": [
{
// Name of configuration; appears in the launch configuration drop down menu.
"name": "Launch app",
// Type of configuration. Possible values: "node", "mono".
"type": "node",
// Workspace relative or absolute path to the program.
"program": "./bin/www",
// Automatically stop program after launch.
"stopOnEntry": true,
// Command line arguments passed to the program.
"args": [],
// Workspace relative or absolute path to the working directory of the program being debugged. Default is the current workspace.
"cwd": ".",
// Workspace relative or absolute path to the runtime executable to be used. Default is the runtime executable on the PATH.
"runtimeExecutable": null,
// Environment variables passed to the program.
"env": { }
},
{
"name": "Attach",
"type": "node",
// TCP/IP address. Default is "localhost".
"address": "localhost",
// Port to attach to.
"port": 5858
}
]
}
Just ran into the same issue... Code couldn't find Node.
Change this line to point to your executable, for example:
"runtimeExecutable": "C:/Program Files/nodejs/node.exe",
Enjoy!
Might be the cluster thing. Try to turn off cluster in ./bin/www, and you will be able to debug it.

Nodejs with TypeScript gives weird errors

I am using TypeScript 1.5.0-beta and I am using Visual Studio Code to create a simple Node Server using an example that Anders Hejlsberg showed at build.
///<reference path="typings/node/node.d.ts"/>
import { createServer } from "http"
export function simpleServer(port: number, message: string)
{
createServer((req, res) =>
{
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(port, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');
}
I have three issues
1) With this code, whenever I try to build the ts file either using Visual Studio Code or the command $ tsc server -m commonjs, it keeps giving weird errors like these
error TS1008: Unexpected token; 'module
, class, interface, enum, import or statement' expected
2) It also tries to build node.d.ts file that I am referencing and gives additional ":" expected error messages.
3) This is more of a Visual Studio Code question. How do we get VS Code to build all ts files in a project/folder and generate js files.
I followed the instructions for the typescript setup for VS Code but I still have to individually build each ts file to gen the js code.
I know grunt is one way to do it but as far as I know VS Code should be able to build all ts files in a folder like Visual Studio does. Please correct me if I am wrong.
Thanks.
Ok, I was finally able to figure out what is going on. Since I had Visual Studio 2013 and TypeScript 1.4 installed, it created the files under C:/Program Files (x86)/Microsft SDKs/TypeScript/1.0. So, every time I use the tsc command, it was always defaulting to version 1.0.3.0 which works with TypeScript 1.4 and not 1.5.0-beta. When I install TypeScript 1.5.0-beta through node, it created the files for new version under C:\Users\Krishna V\AppData\Roaming\npm\tsc
So, for #1, to fix the compilation version issue, I changed the task.json file to use the full path for the command and windows options. So, it will look like this
{
"version": "0.1.0",
// The command is tsc.
"command": "C:\\Users\\Krishna^ V\\AppData\\Roaming\\npm\\tsc",
// Show the output window only if unrecognized errors occur.
"showOutput": "silent",
// Under windows use tsc.exe. This ensures we don't need a shell.
"windows": {
"command": "C:\\Users\\Krishna^ V\\AppData\\Roaming\\npm\\tsc"
},
// args is the HelloWorld program to compile.
"args": [],
"isShellCommand": true,
// use the standard tsc problem matcher to find compile problems
// in the output.
"problemMatcher": "$tsc"
}
For #2, seems like its a know issues with Node.d.ts being out of sync with TypeScript 1.5.0-beta and there are already similar issues with react.d.ts opened in git for this.
For #3, tsconfig.json only works with TypeScript version 1.5.0-beta and since tsc was using the wrong version, it was never using tsconfig. Now that its using the right version, its using the tsconfig and hence it builds all the files mentioned in tsconfig. For example, either of these (one with ES5 and ES6)
{
"compilerOptions": {
"target": "ES5",
"module": "commonjs",
"sourceMap": true,
"removeComments": true
},
"files": [
"server.ts","config.ts","models/user.ts"
]
}
OR
{
"compilerOptions": {
"target": "ES6",
"sourceMap": true,
"removeComments": true
},
"filesGlob": [
"./**/*.ts"
]
}
In this case, it will compile the three files mentioned in first option or all ts files in option 2.
1 - Module Error
This will be resolved when you move to tsconfig.json under #3 below
2 - Reference error with :
The syntax for the reference should be
import http = require('http');
3 - Automated compilation of ts files to js
Configure tsconfig.json file with your settings
(optional) turn on auto save feature in Visual Studio Code
Configure a task in Visual Studio Code
Use the watch feature in the TypeScript compiler
Here is the tsconfig.json
{
"compilerOptions": {
"module": "commonjs",
"noImplicitAny": false,
"removeComments": true,
"preserveConstEnums": true,
"target": "ES5",
"sourceMap": true,
"outDir": "../dist"
}
}
Here is a defined task .settings/tasks.json
--p specifies that you want to compile via a tsconfig.json
--w specifies that you want to recompile when files are saved
You can refer to the compiler options here
{
"version": "0.1.0",
// The command is tsc.
"command": "tsc",
// Show the output window only if unrecognized errors occur.
"showOutput": "silent",
// Under windows use tsc.exe. This ensures we don't need a shell.
"windows": {
"command": "tsc.exe"
},
// args is the HelloWorld program to compile.
"args": ["--p", "./PATH-TO-TSCONFIG-FOLDER", "--w"],
// use the standard tsc problem matcher to find compile problems
// in the output.
"problemMatcher": "$tsc"
}
Node + TypeScript = Awesome!
I can't help you with #3, as I haven't quite tried out VS Code yet. However, on #1 and #2, there are a couple things you need to do:
A.) Enable the CommonJS module type on the Typescript compiler. In Visual Studio, you would do this by going to Project --> Properties --> Typescript Build, and changing the "Module system" to "CommonJS". On the command prompt, you would do this by passing in the parameter "-module commonjs" to tsc.exe. Sorry, I don't know how to achieve this in VS Code.
B.) I think the sample code should look something like this. I'm not sure if Anders may have been giving a sneak preview of future syntax at the conference, but the following should work for you:
///<reference path="typings/node/node.d.ts"/>
import Http = require('http')
export function simpleServer(port: number, message: string)
{
Http.createServer((req, res) =>
{
res.writeHead(200, { 'Content-Type': 'text/plain' });
res.end('Hello World\n');
}).listen(port, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');
}

Resources