I am new to Haxe was trying to compile a .hx file. This file uses ExprRequire. Is this class deprecated from the latest versions? Everytime, I compile I get class not found ExprRequire. I do not also see any file name ExprRequire.hx at \haxe\std\haxe\macro with haxe versions 2.0.7 and 2.0.8.
If this file is deprecated what class should I be using to replace it. Also if someone could place a simple code that could help me understand the migration from ExprRequire to the other class.
-Kshitiz
Have you tried adding import haxe.macro.Expr; ? As far as I known, ExprRequire is defined within haxe.macro.Expr module. You can read more about modules here.
ExprRequire is found in haxe.macro.Expr. It is actually a replacement for a regular Expr, that includes a type for type completion when using the macro. To use that file, all you should have to do is add import haxe.macro.Expr; to the top of the file with the other imports.
Related
I'm trying to get a handle on Node and ES modules. Specifically how/if you can omit the file extension from the path string value of the import statement (and optionally get VSCode to autocomplete those paths).
I understand you can either gives files the .mjs extension or set "type" = "modules" in the package.json but both approaches lead to the following problems.
VSCode won't autocomplete the path if the file extension is .mjs, it only sees the file if it's .js. However if it is .js the autocomplete omits the extension from the string and the import fails until I add it manually.
Trying to use a library like graphql inside my own modules also fails because all the import statements between the .mjs files in the graphql module have been written omitting the extension from the string.
SO... when is not including the extension valid with ES6 module imports, and is there anyway to get this condition enabled with NodeJS?
The node.js ES6 module implementation specifically does not do automatic file extension resolution as documented in https://nodejs.org/api/esm.html#esm_customizing_esm_specifier_resolution_algorithm :
The current specifier resolution does not support all default behavior of the CommonJS loader. One of the behavior differences is automatic resolution of file extensions and the ability to import directories that have an index file.
However this can be changed by a command line argument --experimental-specifier-resolution=[mode]
As such not giving a file extension is invalid by default but can be made valid depending on how you run node.js.
However, there are systems implemented before the ES6 spec was written that implements ES6-like import syntax such as Typescript and Babel. These systems assumed you can exclude file extensions in your imports. If you are using such a system to compile your ES6 imports to ES5 syntax you can exclude file extensions, sometimes, depending on if the version of the compiler you are using supports it.
I need to find out why some module gets included into compilation.
There is some class that should not be included and I think there are some unused imports or bad architecture that requires unnecessary imports. Is there a way to find which modules import some module, which modules import these modules that include this module, and so on, tracking that down to main class of application?
You could use -D dump-dependencies for this, in which case the compiler will generate two files that can be used to follow the dependency graph in both directions:
dump/<target>/.dependants.dump
dump/<target>/.dependencies.dump
There is also a handy online tool created by Mark Knol that helps a lot with analyzing these files. To answer the question "what does Array depend on?", you can just upload the two files and enter "array" into the search field:
Conveniently, the results are also clickable.
I've just came up with very simple idea: just delete this file and there will be compilation errors in places where this module is imported.
I'm trying to use a session helper called connect-session-knex which is obscure enough that it does not have a published typescript definition. So when I try to compile my typescript node project, I get the error,
error TS2307 Cannot find module 'connect-session-knex'
Is there a way to ignore TS for this module only? How do I import it without the TSD? I know knex has a tsd, but the wrapper does not. I'm asking this from a generic standpoint of what to do with libraries without type definitions.
For anyone looking: Compiling typescript when it does not have tsd. Missing tsd. Without tsd.
error TS2307 Cannot find module 'connect-session-knex'
Is there a way to ignore TS for this module only? How do I import it without the TSD?
Use var/require instead of import/require. i.e.
var csk = require('connect-session-knex');
Note you should have node.d.ts included for require to be declared.
Also : https://basarat.gitbooks.io/typescript/content/docs/node/nodejs.html
Another suggestion is to start you own .d.ts file as an empty definition file and export the module. Then if you want to get intellisense on the module you can add definitions to it.
e.g. connect-session-knex.d.ts:
// declare module
declare module "connect-session-knex" {
}
I am currently working on a Node.JS project written in TypeScript using Node.JS Tools for Visual Studio (NTVS). I have a few classes and enums spread out in 3 or 4 files in my project. I am now trying to use the classes defined in those files from my main app file. From my previous work with Node, I know that I would normally need a require call to import each other file/class if I were working with a text editor and the command-line compiler. But, if I open any TypeScript file in my project and start typing the name of a class defined in a different file, Visual Studio shows IntelliSense autocomplete for the class name and its members. This makes me think that the NTVS and/or TypeScript configuration are automatically making all of my classes available project-wide. But if I click the 'run' button, errors are printed to the console because Node can't find the referenced classes at runtime.
This behavior leads me to believe that IntelliSense isn't actually telling me that the classes are available, just that they exist (which seems odd). If I add a require call to the top of the file, and use that imported value instead of the original class name, Node finds the class and I can use it in my code. But this presents two problems:
I must come up with a new name to use for the variable that I import the class into. If I require() it with the original name, Visual Studio shows errors saying that the identifier is a duplicate, because it seems to believe that the original class is available project-wide.
I don't get the autocomplete or type checking in my usage of the class. This pretty much defeats the purpose of using TypeScript.
So, what's the proper way to do this import? Is there a way to make all my classes available globally? If not, what import statements do I need?
This behavior leads me to believe that IntelliSense isn't actually telling me that the classes are available, just that they exist
unless you have top level import or export statement the file is considered a global module and is available project wide : http://basarat.gitbooks.io/typescript/content/docs/project/modules.html
A global module will not work at runtime in node.js
You should use file level modules using import/export and compile with --module commonjs
I want to import a normal javascript module (e.g. vhost) into my node.js typescript file using CommonJS.
I can do this with the following line:
import vhost = require('vhost')
We assume that I can't find a .d.ts file on the internet, but I also don't want to write it by myself, so I just use the vhost variable without intellisense.
The compiler complains and complains:
How can I tell that I just want it to be 'dynamic' (like the C# dynamic keyword or 'var' in normal javascript) and use all of the things in the picture above?
I could create a vhost.d.ts file, but I don't know what to write in there:
declare module 'vash' {
// what to write here?
}
I found this out while typing the question, it was so easy that it is almost embarrassing, but maybe somebody has this problem too.
Just use var instead of import: