I've been stuck on something for some time now. I'm trying to use WebAssembly from Node.js, but in order to do that, I need NodeJs to instantiate a Wasi object. This is implemented here: https://github.com/nodejs/node/blob/master/lib/wasi.js and the documentation is here: https://nodejs.org/api/wasi.html
It is imported through import { WASI } from 'wasi';
But I have no idea how to access the correct wasi implementation, when I add wasi to the dependencies it will install https://www.npmjs.com/package/wasi which is an old user implementation which I don't need. It also does not conform the API documentation from above, it is not usable. My IDE's (WebStorm) code inspection features act as if it is the correct implementation, but when executing the code, it becomes clear it's using a wrong implementation.
If I don't install any at all package I get Cannot find package 'wasi' imported from ...
So the question is, how do I use the WASI class declared in https://github.com/nodejs/node/blob/master/lib/wasi.js?
The solution is to include the command line argument --experimental-wasi-unstable-preview1 when running node! (noted underneath the code example in https://nodejs.org/api/wasi.html)
Ex: node --experimental-wasi-unstable-preview1 index.js
Related
I’m trying to write a library using the new Kotlin/JS IR compiler. Specifically, I want to write the library using Kotlin, but to publish it as a NPM package to be used in a Typescript/Node project.
I have a NPM dependency in the project defined which already has TS types defined and a readily available.
To allow the library to work smoothly together with using it in tandem with this dependency in a project it would make sense to use the already defined TS types when available.
As an example, I want to define a function in my library foo(message: Message) where Message is actually a type coming from the NPM dependency.
What I hoped to be able to achieve would be an output where the generated types in my compiled output contained something like this:
import * as someDep from 'some-dependency'
export namespace foo.bar.baz {
function foo(message: someDep.Message): void;
}
However, I haven’t been able to get this done. Instead, the Message is simply just there as an undefined type, meaning the d.ts file is essentially broken.
For an example of a simple project which tries to do what I’m asking about see: GitHub - jsfr/sample-kotlin-js
Here I create a simple abstract class named Consumer which should be able to take a Message type from the external google-protobuf NPM library. However, in the resulting d.ts file the Message is present with no definition of itself.
Is what I’m trying to do here possible or is there some other approach I should take instead? This seems like an important thing to be able to do for good interoperability.
I'm transforming a small express api to use TypeScript, but some of the packages don't have a #types/ so when I import them I get a TS2307 error.
Is there something I can do to resolve the error? Or maybe type it myself, depending on the package complexity. One example is express-bearer-token(found here)
The quick way is to create a globals.d.ts file and add the line:
declare module "express-bearer-token";
This will treat express-bearer-token as a JS module without typings. More information about that here.
From there, you can start adding more typings yourself if you wish. You can find some information about writing your own definitions here.
For daisyui
Create global.d.ts in the root directory
Add the below line
declare module "daisyui";
Note: Stop the server and re-start if you the server is running already.
I am building a custom binary of NodeJS from the latest code base for an embedded system. I have a couple modules that I would like to ship as standard with the binary - or even run a custom script the is compiled into the binary and can be invoked through a command line option.
So two questions:
1) I vaguely remember that node allowed to include custom modules during build time but I went through the latest 5.9.0 configure script and I can't see anything related - or maybe I am missing it.
2) Did someone already do something similar? If yes, what were the best practices you came up with?
I am not looking for something like Electron or other binary bundlers but actually building into the node binary.
Thanks,
Andy
So I guess I figure it out much faster that I thought.
For anyone else, you can add any NPM module to it and just add the actual source files to the node.gyp configuration file.
Compile it and run the custom binary. It's all in there now.
> var cmu = require("cmu");
undefined
> cmu
{ version: [Function] }
> cmu.version()
'It worked!'
> `
After studying this for quite a while, I have to say that the flyandi's answer is not quite true. You cannot add any NPM module just by adding it to the node.gyp.
You can only add pure JavaScript modules this way. To be able to embed a C++ module (I deliberately don't use the word "native", because that one is quite ambiguous in nodeJS terminology - just look at the sources).
To summarize this:
To embed a JS module to your custom nodejs, just add it in the library_files section of the node.gyp file. Also note that it should be placed within the lib folder, otherwise you'll have troubles requiring the module. That's because the name/path listed in node.gyp / library_files is used to encode the id of the module in the node_javascript.cc intermediate file which is then used when searching for the built-in modules.
To embed a native module is much more difficult. The best way I have found so far is to build the module as a static library instead of dynamic, which for cmake(-js) based module you can achieve by changing the SHARED parameter to STATIC like this:
add_library(${PROJECT_NAME} STATIC ${SRC})
instead of:
add_library(${PROJECT_NAME} SHARED ${SRC})
And also changing the suffix:
set_target_properties(
${PROJECT_NAME}
PROPERTIES
PREFIX ""
SUFFIX ".lib") /* instead of .node */
Then you can link it from node.gyp by adding this section:
'link_settings': {
'libraries' : [
"path/to/my/library.lib",
#...add other static dependencies
],
},
(how to do this with node-gyp based project should be quite ease to google)
This allows you to build the module, but you won't be able to require it, because require() function in node can only be used to load built-in JS modules, external JS modules or external dynamic node modules. But now we have a built-in C++ module. Well, lot of node integrated modules are C++, but they always have a JS wrapper in /lib, and those wrappers they use process.binding() to load the C++ module. That is, process.binding() is sort of a require() function for integrated C++ modules.
That said, we also need to call require.binding() instead of require to load our integrated module. To be able to do that, we have to make our module "built-in" first.
We can do that by replacing
NODE_MODULE(mymodule, InitAll)
int the module definition with
NODE_BUILTIN_MODULE_CONTEXT_AWARE(mymodule, InitAll)
which will register it as internal module and from now on we can process.binding() it.
Note that NODE_BUILTIN_MODULE_CONTEXT_AWARE is not defined in node.h as NODE_MODULE but in node_internals.h so you either have to include that one, or copy the macro definition over to your cpp file (the first one is of course better because the nodejs API tends to change quite often...).
The last thing we need to do is to list our newly integrated module among the others so that the node knows to initialize them (that is include them within the list of modules used when searching for the modules loaded with process.binding()). In node_internals.h there is this macro:
#define NODE_BUILTIN_STANDARD_MODULES(V) \
V(async_wrap) \
V(buffer) \
V(cares_wrap) \
...
So just add the your module to the list the same way as the others V(mymodule).
I might have forgotten some step, so ask in the comments if you think I have missed something.
If you wonder why would anyone even want to do this... You can come up with several reasons, but here's one most important to me: Those package managers used to pack your project within one executable (like pkg or nexe) work only with node-gyp based modules. If you, like me, need to use cmake based module, the final executable won't work...
So far I have a need for two of them, util and fs. Given a code like this:
var fs = require('fs');
var contents = fs.readFileSync('path/to/file', 'utf8');
Not only IntelliJ marks readFileSync as Unresolved function or method, but I am also devoid of, in my opinion, on of the best function given by IDEs - code hinting.
How can I annotate core Node.js functions with JSDoc to have code hinting and not have correct code erroneously marked as invalid?
Why core libraries are not resolved?
The issue with the invalid code is that you have "not NodeJS project".
You should install the NodeJS plugin: http://plugins.jetbrains.com/plugin/6098?pr=phpStorm
And then create a new project with the given sources.
IntelliJ will automatically overwrite the metadata and hook the NodeJS environment and all your core modules will be resolved.
Why there is no code completion?
IntelliJ tries hard do determine the object signature, but some JS coding techniques prevent your IDE from reading the signature (it can be read only in runtime).
Regarding the type annotation you can have a look here, for example: https://groups.google.com/forum/#!topic/scripted-dev/xFtPiBJDO4c
Update: I have written an article describing how you can enable the type hinting for NodeJS in IntelliJ IDEA: http://www.fse.guru/nodejs-autocomplete-in-idea-and-webstorm
I am creating my first Bower component. After running bower init the script asks me 'what types of modules does this package expose?' with these options:
amd
es6
globals
node
what is the difference between these options?
If you don't know, it's quite likely globals is the right answer for you.
Either way, you need to understand:
what is and why AMD
what is a nodejs module
what is ecmascript 6 and especially es6 modules
[UPDATE]
This feature was introduced very recently in bower and is not documented at all yet (AFAIK). It essentially describes the moduleType, which states for what module technology the package is meant to be consumed (see above).
Right now, It doesn't have any effect apart from setting the moduleType property in the bower.json file of the package.
See https://github.com/bower/bower/pull/934 for the original pull-request.
[UPDATE #2]
A few additional points, to answer comments:
right now AFAIK there is no validation done on the moduleType property - which means that people are technically allowed to use whatever value they want for it, including angularjs if they feel inclined to do so
the bower committee seems to not be keen toward the inclusion of additional non-interoperable/proprietary moduleTypes (think composer, angular, etc) - which is easily understandable, but yet again, nothing really prevents people from using the moduleType value they want
an exception to the previous is the (somewhat) recent inclusion of the yui moduleType, so, there are "exceptions" to be made, assuming they are part of a concerted plan
What I would do if I were to author a package for a not-listed package manager and publish it on bower?
I would author an es6 module, and use / patch es6-transpiler to output the package format I need. Then I would either/and:
petition the bower guys to include my package technology as a choice (based on the fact it's supported by es6-transpiler as a target)
publish my package including both the es6 module version of it and the transpiled XXX version of it, and use es6 as a moduleType
Disclaimer: I don't have real-life experience authoring angularjs modules.
Initial
I'm using bower init for first time too.
The options should refer to the different ways to modularize some JavaScript code:
amd: using AMD define, like requirejs.
node: using Node.js require.
globals: using JavaScript module pattern to expose a global variable (like window.JQuery).
es6: using upcoming EcmaScript6 module feature.
In my case I wrote a Node.js module dflow but I'm using browserify to create a dist/dflow.js file that exports a global dflow var: so I selected globals.
Other Updates
The command I used to browserify dflow as a window global object was
browserify -s dflow -e index.js -o dist/dflow.js
I changed it cause I prefer to use require also inside the browser, so now I am using
browserify -r ./index.js:dflow -o dist/dflow.js
and so I changed the bower.moduleType to node in my bower.json file.
The main motivation was that if my module name has a dash, for example my project flow-view, I need to camelize the global name in flowView.
This new approach has two other benefits:
Node and browser interface are the same. Using require on both client side and server side, let me write only once the code examples, and reuse them easily on both contexts.
I use npm scripts and so, I can take advantage of ${npm_package_name} variable and write once the script I use to browserify.
This is another topic, but, it is really worth that you consider how it is useful the latter benefit: let me share the npm.scripts.browserify attribute I use in my package.json
"browserify": "browserify -r ./index.js:${npm_package_name} -o dist/${npm_package_name}.js"
Just for reference, this is precisely what bower specifies regarding the module types:
The type of module defined in the main JavaScript file. Can be one or an array of the following strings:
globals: JavaScript module that adds to global namespace, using window.namespace or this.namespace syntax
amd: JavaScript module compatible with AMD, like RequireJS, using define() syntax
node: JavaScript module compatible with node and CommonJS using module.exports syntax
es6: JavaScript module compatible with ECMAScript 6 modules, using export and import syntax
yui: JavaScript module compatible with YUI Modules, using YUI.add() syntax
Relevant link: https://github.com/bower/spec/blob/master/json.md#moduletype