We Keep Coding

How to properly delay the loading of a Node/Express API using tasks.json in VS Code

I've got a microservices project which I debug in a single VS Code instance. I use Compounds in launch.json to launch/debug.
There's a "Metadata" service which all other services are dependent on, so it needs to be running before any others start up.
I had this solved and it has worked swimmingly for me, for the last 10 months, but it spontaneously broke, recently.
Here's what I've got.
launch.json:
Compound:
{
"name": "API-only",
"stopAll": true,
"configurations": [
"Metadata API",
"Auth API"
]
}
...and the individual API configs in the compound:
{
"type": "node",
"request": "launch",
"name": "Metadata API",
"program": "${workspaceFolder}/metadata-api/bin/www",
"envFile": "${workspaceFolder}/metadata-api/.env",
"skipFiles": [
"<node_internals>/**/*.js",
"${workspaceRoot}/node_modules/**/*.js"
],
"presentation": {
"hidden": false,
"group": "apis",
"order": 1
}
},
{
"type": "node",
"request": "launch",
"name": "Auth API",
"program": "${workspaceFolder}/auth-api/bin/www",
"envFile": "${workspaceFolder}/auth-api/.env",
"skipFiles": [
"<node_internals>/**/*.js",
"${workspaceRoot}/node_modules/**/*.js"
],
"preLaunchTask": "Preload Delay",
"presentation": {
"hidden": true,
"group": "",
"order": 1
}
}
You can see the "preLaunchTask" is set in Auth API but not Metadata API. Here's that:
tasks.json:
{
"version": "2.0.0",
"tasks": [
{
"label": "Preload Delay",
"type": "shell",
"command": "sleep 3",
"windows": {
"command": "ping 127.0.0.1 -n 3 > nul"
},
"group": "none",
"presentation": {
"reveal": "silent",
"panel": "shared",
"revealProblems": "onProblem"
}
}
]
}
I used to be able to watch Metadata load first, then Auth after 3 seconds, in the VSC Call Stack panel. Now, they both show up immediately and often, Auth fails because it's no longer respecting the delay to wait for Metadata to load first, so it can make calls to it and load, itself.
Sure enough, if I manually start Metadata first, or manually pause Auth to wait for Metadata to load, it works every time.
None of this configuration has changed in over 10 months now, so I suspect a recent VSC update had to have broken this? Is there another way? I'm not finding much to go on, out there.

I went through the VS Code documentation and found two problems with your tasks.json.
1-You need to create two different tasks separately for the above mentioned scenario like this e.g
{
"version": "2.0.0",
"tasks": [{
"label": "Client Build",
"command": "gulp",
"args": ["build"],
"options": {
"cwd": "${workspaceFolder}/client"
}
},
{
"label": "Server Build",
"command": "gulp",
"args": ["build"],
"options": {
"cwd": "${workspaceFolder}/server"
}
},
{
"label": "Build",
"dependsOn": ["Client Build", "Server Build"]
}
]
}
2- You need to set "dependsOrder": "sequence" and configure dependencies like e.g.
{
"label": "One",
"type": "shell",
"command": "echo Hello ",
"dependsOrder": "sequence",
"dependsOn": ["Two", "Three"]
}
Find out More about compound tasks?
Good Luck!

How to fix gulp windows script host error in vscode

Gulp watch task runner error. It results in a windows script host error.
I've already tried to change the file task.json:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"command": "gulp",
"isShellCommand": true,
"args": [
"--no-color"
],
"tasks": [
{
"taskName": "scripts",
"isBuildCommand": true,
"showOutput": "always"
},
{
"taskName": "sass",
"isBuildCommand": true,
"showOutput": "always"
},
{
"taskName": "watch",
"isBuildCommand": true,
"showOutput": "always"
}
]
}

It looks like you are using older syntax. I don't believe taskname is supported anymore for example.
Here is a tasks.json file that I use and both methods of calling gulp commands work. (You mentioned task.json, I assume that is a typo, it is tasks.json)
{
"version": "2.0.0",
"tasks": [
{
"label": "Start server and process files",
"command": "gulp",
"args": [
"sync"
],
"type": "shell",
"options": {
"cwd": "${workspaceRoot}"
}
},
{
"label": "Gulp: Start server only",
"type": "gulp",
"task": "serve",
"problemMatcher": []
},
{
"label": "Gulp: watch",
"type": "gulp",
"task": "watch",
"problemMatcher": []
}
}
It looks like you also want:
"group": "build",
in each of your tasks - that replaces the isBuildCommand syntax you used above.
And:
"presentation": {
"reveal": "always",
},
instead of the showoutput syntax.
See migrating to tasks 2.0 documentation.

How to associate a file extension to an electron app (multiplatform)

I already added the following snippet to my package.json:
"build": {
"fileAssociations": [
{
"ext": "asdf",
"name": "ASDF File",
"role": "Editor"
}
]
}
But the generated installer does not assign my application to the asdf extension. (tested on Windows 10)
I also looked up, how to edit the setupEvents.js file. It contains the following part:
case '--squirrel-updated':
// Optionally do things such as:
// - Add your .exe to the PATH
// - Write to the registry for things like file associations and
// explorer context menus
But I could not find a single example, how to archieve the registry writing part.

Add the "perMachine": true, option, e.g.:
"build": {
"fileAssociations": [
{
"ext": "asdf",
"name": "ASDF File",
"role": "Editor",
"perMachine": true
}
]
}
The reason it is needed, is because on Windows, per-user installed program cannot register file associations, and that is the default setting.

It seems that with the newer version you need to set it like this
"build": {
"fileAssociations": [{
"ext": "ext1",
"name": "ext1 File",
"role": "Editor"
},
{
"ext": "ext2",
"name": "ext2File",
"role": "Editor"
}
],
"nsis": {
//othersettings,
"perMachine": true
}
}
there is more information about other file association settings here

OpenComponents returns TEMPLATE_NOT_SUPPORTED_ERROR for custom compiler

I'm trying to setup OpenComponents with custom compiler (based on oc-template-react).
My component's package.json:
{
"name": "hi-there",
"description": "Hello World OC",
"version": "1.0.0",
"oc": {
"files": {
"data": "server.js",
"template": {
"src": "app.js",
"type": "oc-my-template"
}
},
"parameters": {
"name": {
"default": "World",
"description": "Your name",
"example": "Jane Doe",
"mandatory": false,
"type": "string"
}
}
},
"devDependencies": {
"oc-my-template-compiler": "*"
}
}
oc-my-template-compiler is installed. Packaging works fine, but I'm getting following error from registry:
GET http://localhost:3030/hi-there/1.0.0/?__oc_Retry=0
{
code: "TEMPLATE_NOT_SUPPORTED"
error: "oc-my-template is not a supported oc-template"
name: "hi-there"
requestVersion: "1.0.0"
}
I think I should register template with oc.registerTemplate but I'm not sure where should I do it. Should not dev registry take care about it?

If you look into the "oc-client" component (visiting http://localhost:3030/oc-client) you should have a snippet of what is required to correctly render your component with the custom template.
One common thing to do if you are using OC in a dynamic web app, is to server-side render the oc-client component in order to serve the html page with the oc-client already initialised with all the supported templates.

Intern 4 tests fail to load the Dojo2 loader

I'm migrating from Intern 3/requirejs to Intern 4/dojo2. I'm trying to run a test and immediately after the capabilities checks it will fail before ever loading my tests with this error:
Listening on localhost:9000 (ws 9001)
Tunnel started
‣ Created remote session chrome 66.0.3359.139 on XP (bc531663-f9f7-4cba-9038-6ab15808e9a0)
Suite chrome 66.0.3359.139 on XP FAILED
Error: Unable to load /..\node_modules\intern/loaders/dojo2.js
at HTMLScriptElement.<anonymous> <node_modules\intern\browser\remote.js:667:23264>
TOTAL: tested 1 platforms, 0 passed, 0 failed; suite error occurred
It's 404ing on that file from http://localhost:9000/__intern/browser/remote.html because it's trying to get dojo2.js from the wrong path by the looks of it. If I replace dojo2 in my config script with __intern/loaders/dojo2.js it will then 404 on /node_modules/#dojo/loader/loader.js. It looks like it's just looking for the wrong paths, is there something I can do to fix this?
intern.json
{
"loader": {
"script": "dojo2",
"config": {
"waitSeconds": 60,
"packages": [ {
"name": "objects",
"location": "objects"
}, {
"name": "edits",
"location": "./",
"main": "edits"
}, {
"name": "prepare",
"location": "TESTS",
"main": "prepare"
}, {
"name": "common",
"location": "./",
"main": "common"
}, {
"name": "socket",
"location": "http://localhost:2020/socket.io",
"main": "socket.io"
}
]
}
},
"suites": [
"./functional/InitTests.js"
],
"environments": [ {
"browserName": "chrome"
}
],
"tunnelOptions": {
"drivers": [
"chrome"
],
"port": 4444,
"version": "3.4.0",
"maxConcurrency": 1,
"runnerClientReporter": {
"writeHtml": false
}
},
"tunnel": "null",
"leaveRemoteOpen": true,
"grep": ""
}

There are a few potential issues:
Have you installed #dojo/loader? The loader scripts require that the associated loader be installed as a peer of Intern.
When using an AMD loader, specify tests as module IDs rather than file names
Does ./functional/InitTests.js actually contain functional tests? If so, it should be specified under functionalSuites.