If I, in node.js 6.6, write (resp. have transpiled from TypeScript) a class like that:
class Table {
constructor(args) {
this._rows = new Proxy({ test: 42 }, {});
}
}
And instantiate it like this:
var table = new Table();
When I debug in Visual Studio Code 1.2.1 when I want to watch the var table I always have
Internal error: illegal access
written there, meaning I can not watch table or any of its properties.
The same thing works perfectly fine in Chrome.
So, why is that and what can I do about it?
Thanks!
For those coming here first. It is indeed a bug this happens however Microsoft traced it to depreciated v8 debug code inside node.js itself. The workaround is to use "type": "node2" in your launch configuration file. This tells vscode to use the new debug protocol. Node 7+ is also recommended. Support for both is considered experimental as of vscode 1.10 and should used only if needed.
As of vscode 1.10 the "node2" code is being merged with "node". "type":"node2" is depreciated in favor of the "protocol" attribute. If set to "auto" the protocol will be switched automatically based on runtime determination. Setting to attribute to "inspector" simulates the effects of "node2" forcing the new debug protocol to be used. The default setting is equivalent to using "type":"node" in vscode 1.8.x, 1.9.x.
Related
I know that the ES6 export/import syntax is not part of Node.JS yet, so when I write a class in Node.JS, it usually goes something like this:
class Foo {
...
}
module.exports = Foo;
However, I frequently see a slightly more compact version of this:
module.exports = class Foo { ... }
When I write this code in WebStorm it will however complain "expression expected" (it doesn't like the class keyword in an assignment). The file seems to work fine when run with Node (~6.10) though.
Is there a compatibility setting in WebStorm to allow this? The only option I found was an inspection for warning about non-ES6 draft features.
WebStorm has issues resolving members of classes exported this way (see WEB-28158), but the syntax itself is correctly accepted (WebStorm 2017.3.2):
What IDE version do you use? Did you set JavaScript Language Version to ECMAScript 6 in Settings | Languages & Frameworks | JavaScript?
If this doesn't help, try invalidating caches
I have an F# Azure Function that is failing, in a bizarre way, and don't know how to approach fixing the issue. I created a minimum repro of the actual case below. The test function is manually triggered and uses FSharp.Compiler.Service as a dependency, as specified in the project.json below:
{
"frameworks": {
"net46":{
"dependencies": {
"FSharp.Compiler.Service": "11.0.6"
}
}
}
}
The run.fsx file looks like this:
open System
open Microsoft.FSharp.Compiler
open Microsoft.FSharp.Compiler.Ast
open Microsoft.FSharp.Compiler.Interactive.Shell
let Run(input: string, log: TraceWriter) =
// code here that uses FsiEvaluationSession
// and runs just fine
log.Info "I RAN"
So far, so good. The part that baffles me is that if I add the following function above Run,
// same dependencies as before
open Microsoft.FSharp.Compiler.Interactive.Shell
let foo (longIdent:LongIdent) =
// version 1
// "FOO"
// version 2
// longIdent.ToString ()
// version 3
longIdent |> List.map string
let Run(input: string, log: TraceWriter) =
// same as before
Uncommenting section 1 alone works fine, uncommenting section 2 alone works fine, uncommenting section 3 causes hell to break loose. The function compiles, but running it causes the following exception:
Exception while executing function: Functions.fsc-1. mscorlib: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
... which is puzzling to me, because
foo isn't even called anywhere
the signature and the 2nd version both use LongIdent, so this type doesn't seem to be the source of the problem.
Any suggestion on how to approach the problem, and what the problem itself might be, would be very appreciated - I don't even know where to start, and the same code runs perfectly fine in a local script.
I believe the reason for this is that Azure Functions SDK depend on FSharp.Compiler.Service (FCS) version 9.0.1. This means that when you try to load a different version of FCS, you will get the already loaded version 9.0.1.
This works as long as the public API of the FCS version you are using matches the public API of version 9.0.1, but when there are differences, it will crash, because your code assumes that the public API looks different. I suppose this might be triggering the issue here, although I'm not 100% sure how (possibly, LongIdent is now a different thing than it was in version 9.0.1?)
The very same issue used to happen with FAKE, which also bundles FCS and prevented loading of different versions. One of the options is to rename the assembly to avoid the clash.
I also got the same error, I solved it by doing the following workaround, please refer if it works for you also.
Right-click on the Project and select properties.
Goto Debug tab and create a profile with the reference to the below
screenshot.
Note: Replace UserName with your username.
I use debug strings for debugging Loopback 2.0 application. Loopback documentation says:
The LoopBack framework has a number of built-in debug strings to help
with debugging. Specify a string on the command-line via an
environment variable as follows:
MacOS and Linux
$ DEBUG=<pattern>[,<pattern>...] node .
Is it possible to change patterns dynamically in runtime? Or is it possible to use environment-specific configuration?
Before I get deeper note that this debug logging facility uses visionmedia's debug module which handles almost all of the logic.
Is it possible to change patterns dynamically in runtime?
Well before any module is loaded, safest and best way I believe is to just manipulate the environmental variables:
if (process.env.NODE_ENV === 'development') {
process.env.DEBUG = process.env.DEBUG + ',loopback:*';
}
Another way would be to load debug and use it's .enable method:
require('debug').enable('loopabck:*');
But note that it only works if you do this before Loopback is required since it only allows changes before it's instances are created, which is in this case before loopback is loaded. Another thing is that, there might be multiple debug modules installed depending on the dependencies and your package manager(npm#3, npm#2 and yarn behave differently). debug might be in your node_modules directory, or it might be in loopback each module, node_modules directory. So make sure you require all instances of it and enable, if you want to do it this way.
Now if don't want to do it on the startup, well API doesn't allow changes in the runtime. You can view the discussion regarding this here. Though there are some dirty ways to go around it, but these might possibly break in the future so be careful.
Firstly, there's a module called hot-debug which supposedly makes require('debug').enable work on previously created instances also, but when I tried it, it didn't work perfectly and it was buggy, but it's possible it might work fine for you.
If that doesn't work for you another way is to override require('debug').log method. If this is defined, debug will call this method instead of console.log with the formatted the arguments. You can set DEBUG=* and then filter it yourself:
require('debug').log = function (string) {
if (string.contains('loopback:security')) {
console.log(string);
}
};
This way will be slow in production though as all the debug output will be formatted before being filtered even though nothing might be outputted to console.
Another thing to override the require('debug').init method. This is called everytime a new debug instance is created. Since every debug instance uses an enabled property to check if it's enabled we can toggle that.
const debug = require('debug');
const { init } = debug;
const instances = [];
debug.init = function(debugInstance) {
init(debugInstance);
instances.push(debugInstance);
};
// You can call this function later to enable a given namespace like loopback.security.acl
function enableNamespace(namespace) {
instances.forEach(instance => {
instance.enabled = instance.namespace === namespace;
});
}
Though there's a lot of improvement can be done on this, but you get the idea.
I can change debug namespace dynamically with the hot-debug module.
In my app, I've just created a function for this :
require('hot-debug')
const debug = require('debug')
function forceDebugNamespaces (namespaces) {
debug.enable(namespaces)
}
// Usage
forceDebugNamespaces('*,-express:*,-nodemon:*,-nodemon')
In my case, I have a config file which allow me to set process.env.DEBUG but I needed to find a way to update debug namespaces without restarting my app (the config file is watched for changed by my app).
I'm working on a UI component in VIM with TypeScript plugin that highlights the errors on the spot, so it's not something I get during the actual plugin installation into the app at this point (although I haven't tried yet).
declare module "card-view" {
import view = require("ui/core/view");
export class CardView extends view.View {
}
}
And I get this:
Cannot find module 'ui/core/view'.
I realize that ui/core/view is unavailable at this point, since it's a standalone plugin, but it will be available at runtime. Is there anything to be done to resolve the error? I must be missing some step that wasn't mentioned in the guide -- http://docs.nativescript.org/plugins/ui-plugin.
UPDATE 1:
When I got to card-view-common.js implementation I hit another issue. TypeScript expects android and ios properties to be implemented, but since the class extends View (from ui/core/view) they are supposed to be implemented there. In other words, I believe I still need to somehow point to the existing core module, not sure how though.
Found it. I added a devDependency to package.json with tns-core-modules like below, ran npm install and then it began recognizing the module. Makes sense if you think about how it is supposed to compile the module during the development phase without installing in the real app, but may be worth mentioning in the guide anyway.
"devDependencies": {
"tns-core-modules": "^1.5.1"
}
'ui/core/view' (and the modules, distributed through the tns-core-modules package are declared as ambient external modules.
It could be that the vim plugin you use does not recognize ambient modules correctly.
I started using a Web API cache which I add to particular methods by using an aspect [Cache]. Everything worked great. Later on I changed this method to be async, but since then the compiler started throwing following warnings:
The parameter 'region' of method 'GetTree(System.String,
System.String, System.String[])' has been optimized out by the
compiler and will not be available to the aspect. Disable compiler
optimizations to access the parameter.
Here you can see an example of how I am using Postsharp:
[Cache]
public async Task<IEnumerable<Node>> GetTree(
[FromUri] string region,
[FromUri] string language,
[FromUri] string[] networks)
{
...
await ...
}
What do I need to do in order to get rid of the warning?
The C# compiler optimizations remove the parameters from the state machine class if these parameters are not used anywhere inside the async method. This happens regardless of whether you use PostSharp or not. PostSharp shows you the warning to notify that the removed parameters cannot be accessed inside the aspect.
It's recommended to upgrade to the latest build of PostSharp - the newer versions can handle this issue by re-introducing the missing parameters back into the state machine.
If you cannot upgrade, then the workaround is to disable "Optimize code" in the build page of the project properties for release builds (it's disabled for debug builds by default).