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.
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 a node module A depending on another node module B, both written in Typescript. Module B returns Promises to A and have chosen bluebird as the Promise implementation. B of course have typings for bluebird.
However, if A doesn't have typings of bluebird (which it probably shouldn't in my case), I get errors like:
~/d/p/ensime-vscode ❯❯❯ tsc -p . ⏎ master ✭ ✱
node_modules/ensime-client/**/file-utils.d.ts(1,26):
error TS2307: Cannot find module 'bluebird'.
It took me a while to realize that this was due to me leaking the concrete Promise type of bluebird. Changing all the public return types to PromiseLike made the errors go away.
My question is, is there a way to detect these earlier on my independent module B? I recall sometimes getting errors when modules leaked types that wasn't public before, but in this case module B built just fine. It's all very blurry to me this thing since I'm very new to Typescript. I guess Typescript is a different beast compared to what I'm used to.
Also, isn't it possible for tsc to emit better error messages for these cases?
Small update:
When I'm "leaking" a type that is locally defined this is caught directly in B:
export interface CompletionsResponse extends Typehinted {
completions: [Completion]
}
interface Completion {
}
[ts]
Property 'completions' of exported interface has or is using private name 'Completion'.
interface Completion
I would like to be able to catch this kind of thing directly if I'm exposing something from a dependency like 'bluebird'.Promise as well. It was never my intention to expose 'bluebird' as a transitive dependency, and I honestly don't even know how to do that with typings? So as this builds just fine, what has happened is that 'bluebird' silently became a typings "peer dependency" in npm toungue.
If a package has a type dependency on another module, this dependency should be included in the package's typings.json, with typings install bluebird --save.
Your type declaration of module B should look something like this type declaration for redux-persist (but then inside your actual project). It depends on redux for several types. Therefore, there is a dependency listed in the typings.json.
Concerning typescript error messages, they're kind of a pain. ¯\_(ツ)_/¯
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 in the process of trying to migrate a R# extension project from R# 6 to R# 8. (I've taken over a project that someone wrote, and I'm new to writing extensions.)
In the existing v6 project there is a class that derives from RenameWorkflow, and the constructor used to look like this;
public class RenameStepWorkflow : RenameWorkflow
{
public RenameStepWorkflow(ISolution Solution, string ActionId)
: base(Solution, ActionId)
{
}
This used to work in R# SDK v 6, but now in V8, RenameWorkflow no longer has a constructor that takes Solution and actionId. The new constructor signature now looks like this;
public RenameWorkflow(
IShellLocks locks,
SearchDomainFactory searchDomainFactory,
RenameRefactoringService renameRefactoringService,
ISolution solution,
string actionId);
now heres my problem that I need help with (I think)
I've copied the constructor, and now the constructor of this class has to satisfy these new dependancies. Through some digging I've managed to find a way to satisfy all the dependencies, except for 'SearchDomainFactory'. The closest I can come to instantiating via the updated constructor is as follows;
new RenameStepWorkflow(Solution.Locks, JetBrains.ReSharper.Psi.Search.SearchDomainFactory.Instance, RenameRefactoringService.Instance, this.Solution, null)
All looks good, except that JetBrains.ReSharper.Psi.Search.SearchDomainFactory.Instance is marked as Obsolete, and gives me a compile error that I cannot work around, even using #pragma does not allow me to compile the code. The exact error message I get when I compile is Error 16 'JetBrains.ReSharper.Psi.Search.SearchDomainFactory.Instance' is obsolete: 'Inject me!'
Obvious next question..ok, how? How do I 'inject you'? I cannot find any documentation over this new breaking change, in fact, I cannot find any documentation (or sample projects) that even mentions DrivenRefactoringWorkflow or RenameWorkflow, (the classes that now require the new SearchDomainFactory), or any information on SearchDomainFactory.Instance suddenly now obsolete and how to satisfy the need to 'inject' it.
Any help would be most appreciated! Thank you,
regards
Alan
ReSharper has its own IoC container, which is responsible for creating instances of classes, and "injecting" dependencies as constructor parameters. Classes marked with attributes such as [ShellComponent] or [SolutionComponent] are handled by the container, created when the application starts or a solution is loaded, respectively.
Dependencies should be injected as constructor parameters, rather than using methods like GetComponent<TDependency> or static Instance properties, as this allows the container to control dependency lifetime, and ensure you're depending on appropriate components, and not creating leaks - a shell component cannot depend on a solution component for instance, it won't exist when the shell component is being created.
ReSharper introduced the IoC container a few releases ago, and a large proportion of the codebase has been updated to use it correctly, but there are a few hold-outs, where things are still done in a less than ideal manner - static Instance properties and calls to GetComponent. This is what you've encountered. You should be able to get an instance of SearchDomainFactory by putting it as a constructor parameter in your component.
You can find out more about the Component Model (the IoC container and related functionality) in the devguide: https://www.jetbrains.com/resharper/devguide/Platform/ComponentModel.html
If I have a module that requires an application namespace, e.g.:
define(["app"], function(App){
[...]
});
... and the namespace requires libraries used by all of my modules, e.g.:
define(["jquery", "underscore", "backbone"], function($, _, Backbone){
[...]
});
... then all of my modules have access to the libraries required by the namespace, i.e. I can use $, _, and Backbone.
I like this behavior because I can avoid being repetitious, but I suspect that I'm cheating somehow, and that I should require libraries in each module.
Can anyone set me straight here?
Yeah, that's kinda hacky. You only have access to jQuery, underscore and backbone because they're also defined onto the global scope. Backbone and undersocre aren't real AMD module, they have to use a shim config. jQuery declare himself on the global scope and as an AMD module so it works everywhere.
So, yes it work like that, but it's not optimal. Real AMD module (non-shimmed) won't work this way as they need to be passed in the define functions arguments, and you won't be able to pull only one module to test it in a separate environment, etc. This way, you cannot load different versions of a scripts to work with different module/app section/page.
The goal of AMD is to bring modularity to your code so every module declare it's own dependencies and will work out of the box it without relying on the global scope (which is a good thing to prevent name collision and conflict with third party/other dev working on the same project).
If you find it's redundant to redeclare everytime your base dependencie, create a boilerplate file that you just copy/paste when creating another module (it's better than nothing). And, maybe some command line tools can build AMD module wrapper for you.
Soooo, yes it works, but it won't scale if your project ever get bigger or need to be updated pieces by pieces.
Hope this help !
good news for the above answer: underscore 1.6.0 now is wrapped as a amd module :)
see "lib.chartjs" for exporting globals in not amd wrapped "shimmed" javascript libraries
requirejs.config({
paths: {
"moment": "PATH_TO/js/moment/2.5.0/moment.min",
"underscore": "PATH_TO/js/underscore/1.6.0/underscore",
"jquery": "PATH_TO/js/jquery/1.10.2/jquery.min",
"lib.jssignals": "PATH_TO/js/jssignals/1.0.0-268/signals.min",
// WORKAROUND : jQuery plugins + shims
"lib.jquery.address": "PATH_TO/js/jqueryaddress/1.6/jquery-address"
"lib.jquery.bootstrap":"PATH_TO/js/bootstrap/3.0.3/bootstrap",
"lib.chartjs": "PATH_TO/js/chartjs/0.2/Chart.min",
},
shim: {
"lib.jquery.address": {deps: ["jquery"]},
"lib.jquery.bootstrap": {deps: ["jquery"]},
"lib.chartjs": {deps: ["jquery"], exports: "Chart"},
}
});