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
Related
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.
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 am using typescript and requirejs. For the most part the amd modules are generated beautifully. I am however stuck with loading using requirejs json or for that matter text plugin.
define(["json!sometextfile.json"], function(myJson)
How can I do this in typescript. I am using TS 1.6 at the moment.
I'm not sure I have understood your question, but I think you want to know how to call require directly without getting a compiler error... for example:
require(["json!sometextfile.json"], function(myJson) {
});
The quick fix for this is to supply a very open definition for the require function:
declare var require: any;
require(["json!sometextfile.json"], function(myJson) {
});
You can improve upon this crude fix by using the full RequireJS type definition from the Definitely Typed project.
I'm using WebStorm 10.
When I use some lib like bluebird that make code like
var foo = require("foo"); // I will call foo.doSomething
Promise.promisifyAll(foo);
foo.doSomethingAsync(...).then(...)
the doSomethingAsync will be marked as unresolved function inspection.
So what can I do something like config *Async in WebStorm to avoid unresolved function mark?
Best solution at the time is use namespace reserving.
Webstorm supports using comments in order to mark stuff as legitimate:
/** #namespace foo.doSomethingAsync */
var foo = Promise.promisifyAll(require('foo'));
foo.doSomethingAsync(...)
.then(...)
This doesn't solve the actual issue, and won't get you suggestions for the arguments when using the function, but it's surely a convenience, helping clean up the insane amount of warnings generated when promisifying.
I hope this helps..
Got a similar issue when working with TypeScript and Angular 2 (following its Heroes tutorial) using ES2015, but for the Promise object.
Promises are part of the Standard Built-in Objects, so I thought that WebStorm 2016 could use the TypeScript definitions and be able to get it, but by default it didn't.
Everything worked except for this.
So, I went to Settings > Languages & Frameworks > JavaScript and changed the JavaScript language version to ECMAScript 6.
I thought that it would not having nothing to do since I was using TypeScript, but it does.
Now the Promise object reference works and links to lib.es6.d.ts, which is an internal WebStorm definition of ES2015 objects for TypeScript.
After upgrading from IDEA 13.1.x to 14.x (14.0.2 at the moment) I see the support for Spock Framework Mock() and Stub() methods got worse.
To be more specific, I mean in-line methods stubbing/mocking with closures like:
MyType stub = Stub {
myMethod() >> { /* do something */ }
}
IDEA 13 is aware of available methods for stubbed type, which is visible on the below screen shot.
size() method is not underlined. It can be navigated to, auto-completed, checked for possible argument types and so on - usual IDE stuff. The same is possible with any other List method inside of the 'stub closure'.
While IDEA 14 lacks this feature which really is a pity. The screen shot below shows it.
size() method is underlined and greyed out. IDE seems to not have a clue what's up.
The same applies to Mock { } method event if invoked with a type as an argument like Mock(MyType) { } (and Stub(MyType) { } respectively)
My question is - is it only me or that's a bug/regression? Or maybe I need to adjust some settings?
EDIT: seems it's a bug / regression. I raised a bug in youtrack. Up vote, please.
There is a bug in storage system, i.e. GDSL works itself, but state is inconsistent across IDE startups.
As a temporary solution:
Project View -> External Libraries -> spock-core
open org.spockframework.idea.spock.gdsl in Editor
wait until Notification about disabled GDSL comes out
use Activate link in the Notification
You should enable GDSL every time you start up your Idea.
This bug is fixed and the fix will be released asap.