Can't add a database connection to my small react app, i tried a bunch of npm modules: sqlite, sqlite3, realm. All fall back with type error:
TypeError: stream is undefined
i do absolutely nothing, just added a require statement in my component case that error:
import db from 'sqlite';
or:
var sqlite = require('sqlite3').verbose();
The last trace string:
(function (process){
module.exports = function (blocking) {
[process.stdout, process.stderr].forEach(function (stream) {
if (stream._handle && stream.isTTY && typeof stream._handle.setBlocking === 'function') {
stream._handle.setBlocking(blocking)
}
})
}
and real fails on building, with Error: Cannot find module 'AccessibilityInfo'
Your last trace points to the content of set-blocking npm module. Usually it is used by npmlog. It requires process.stderr and process.stdout to be present. In your case they aren't. If you are running the app in Electron that might be the case.
It probably means that you are attempting to run a nodejs library in the browser, and that will not work. You might be able to browserify the library.
Related
What I need:
Read a local JSON file inside NuxtJS as the page loads. So I can parse it into a prop within <option> tag.
What I have:
Lowdb (installed as dependency — to read the JSON file) inside a component, with this code:
computed: {
resultFetchCamera: function() {
const low = require('lowdb')
const FileSync = require('lowdb/adapters/FileSync')
const adapter = new FileSync('db.json');
const db = low(adapter);
let value = db.get('Size').map('Name').value();
return value;
}
}
}
I got an error This dependency was not found: * fs in ./node_modules/lowdb/adapters/FileSync.js. Fixed with this solution. Which leads me to another error: TypeError: fs.existsSync is not a function. This solution helps out a bit but it also leads to other errors: TypeError: window.require is not a function and TypeError: FileSync is not a constructor. So, I undo the last solution and get back with the fs.existsSync error.
The question:
How to fix the fs.existsSync error (in a NuxtJS environment)?
Did I implement Lowdb to NuxtJS correctly?
I got a doozie here. In Electron's main process, I require in the function below to setup event handlers with ipcMain. This keeps the main.js file a little more streamlined. All went swimmingly until I wrote some validation code to ensure that the user passes in an object. I use typeof all the time for this purpose, and never have I had an issue. But in Electron I am getting:
A JavaScript error occurred in the main process - TypeError: Cannot
assign to read only property 'exports' of object '# '
The code:
const {ipcMain} = require('electron');
function ipcSetup() {
ipcMain.on('123', function(event, arg) {
// this blows chunks...
if(arg && typeof arg === 'object') {
console.log(`All good....`);
}
// and if you comment that out, this use of "typeof" does the same thing
console.log(typeof arg);
// and to eliminate 'arg' as the issue...
let a = 1;
console.log(typeof a); // expect 'number', get Exception
});
}
module.exports = ipcSetup;
I didn't know if Electron is using Object.defineProperty to make arg read only, but typeof is not making an assignment here anyway, and I eliminated arg so this error makes no sense. Environment is Electron 1.8.4 on Node 8.2.1 using electron-vue
If you're importing that module in another module that uses ES6 import/export syntax, using typeof apparently causes this. I think this is because webpack doesn't support mixing the two syntaxes. But it is quite funny that it would work fine if you didn't use the typeof operator...
I am building an electron app, where the mainWindow object is created following the quick start: http://electron.atom.io/docs/tutorial/quick-start/.
As per this quick start, it is created asynchronously. The problem that I run into, is that for instance when I want to send messages from main to renderer process, I need to reference the mainWindow object. If this happens to be in a module that I require, then I need a means to make this module know of the mainWindow object.
I could of course prepend it with global., but I know that this is very much advised against. So I wish to do it more elegantly.
I came across this post: Asynchronous nodejs module exports; which appears to offer a solution. Taking the main.js file from the quick start (see above link, it's explicitly shown there), it appears I would add to the createWindow function
if( typeof callback === 'function' ){
callback(mainWindow);
}
and export the main.js module as
module.exports = function(cb){
if(typeof mainWindow !== 'undefined'){
cb(mainWindow);
} else {
callback = cb;
}
}
Then, in a higher-level script, I would require as follows:
let main = require('./main.js');
let lib = require('./lib.js'); // Library where I need a mainWindow reference
main(function(window) {
lib.doSomething(window);
});
where lib.js looks like
module.exports.doSomething = function(window) {
// Do something with window object, like sending ipc messages to it
window.webContents.send('hello-from-main', "hi!");
}
Although the simple case in the original post 'Asynchronous nodejs module exports' works fine, I cannot get it to work like described above; running the app it complains Uncaught Exception: TypeError: Cannot read property 'webContents' of null. This is also the case if I directly require lib.js within main()'s callback (which I know is also advised against).
I confess that I do not fully understand the simple case of the post, as I am rather new to node. This prevents me from fixing my own implementation of it, which I agree is blunt copy/pasting which reasonably should be expected to fail. Could somebody help me with how to correct above method, or advise me of a different approach to make it work? Thank you!
I have created the npm package electron-main-window for the same.
Install:
$ npm install electron-main-window
or
$ yarn add electron-main-window
Usage:
// Import ES6 way
import { getMainWindow } from 'electron-main-window';
const mainWindow = getMainWindow();
// Import ES5 way
const mainWindow = require('electron-main-window').getMainWindow();
// e.g:
if(mainWindow !== null ){
mainWindow.webContents.send('mainWindowCommunication', "This is a test message");
}
Whooops! The devil is in the details... I had defined on top of main.js
let mainWindow = null, callback;
which caused the error! Should be
let mainWindow, callback;
then it works perfectly!
P.s. Instead of deleting my post, I opted for keeping it and answering myself for future reference of other people who need asynchronous exporting.
I'm using node-webkit with an external module called edge.
According to the node-webkit docs modules that contain native code must be recompiled using nw-gyp as oppose to node-gyp. I was able to recompile without error and node-webkit seems to import the module OK.
Heres my code. The code I'm trying to use:
var edge = require('edge.node');
var hello = edge.func(function () {/*
async (input) =>
{
return ".NET welcomes " + input.ToString();
}
*/});
hello('Node.js', function (error, result) {
if (error) throw error;
console.log(result);
});
Which throws the following error when run within node-webkit.
Uncaught TypeError: Object [object Object] has no method 'func'
If write the object out to console.log I can see:
Object {initializeClrFunc: function}
initializeClrFunc: function () { [native code] }
__proto__: Object
So the module seems to have loaded. If I run the same code outside of node-webkit, everything works perfectly and I can access the func function. This is driving me crazy - and any help would be really appreciated.
func method is provided by edge.js, the wrapper around edge.node native module. So you should replace require('edge.node') by require('edge').
How can I detect whether my Node.JS file was called using SH:node path-to-file or JS:require('path-to-file')?
This is the Node.JS equivalent to my previous question in Perl: How can I run my Perl script only if it wasn't loaded with require?
if (require.main === module) {
console.log('called directly');
} else {
console.log('required as a module');
}
See documentation for this here: https://nodejs.org/docs/latest/api/modules.html#modules_accessing_the_main_module
There is another, slightly shorter way (not outlined in the mentioned docs).
var runningAsScript = !module.parent;
I outlined more details about how this all works under the hood in this blog post.
For those using ES Modules (and Node 10.12+), you can use import.meta.url:
import path from 'path';
import { fileURLToPath } from 'url'
const nodePath = path.resolve(process.argv[1]);
const modulePath = path.resolve(fileURLToPath(import.meta.url))
const isRunningDirectlyViaCLI = nodePath === modulePath
Things like require.main, module.parent and __dirname/__filename aren’t available in ESM.
Note: If using ESLint it may choke on this syntax, in which case you’ll need to update to ESLint ^7.2.0 and turn your ecmaVersion up to 11 (2020).
More info: process.argv, import.meta.url
I was a little confused by the terminology used in the explanation(s). So I had to do a couple quick tests.
I found that these produce the same results:
var isCLI = !module.parent;
var isCLI = require.main === module;
And for the other confused people (and to answer the question directly):
var isCLI = require.main === module;
var wasRequired = !isCLI;
Try this if you are using ES6 modules:
if (process.mainModule.filename === __filename) {
console.log('running as main module')
}
I always find myself trying to recall how to write this goddamn code snippet, so I decided to create a simple module for it. It took me a bit to make it work since accessing caller's module info is not straightforward, but it was fun to see how it could be done.
So the idea is to call a module and ask it if the caller module is the main one. We have to figure out the module of the caller function. My first approach was a variation of the accepted answer:
module.exports = function () {
return require.main === module.parent;
};
But that is not guaranteed to work. module.parent points to the module which loaded us into memory, not the one calling us. If it is the caller module that loaded this helper module into memory, we're good. But if it isn't, it won't work. So we need to try something else. My solution was to generate a stack trace and get the caller's module name from there:
module.exports = function () {
// generate a stack trace
const stack = (new Error()).stack;
// the third line refers to our caller
const stackLine = stack.split("\n")[2];
// extract the module name from that line
const callerModuleName = /\((.*):\d+:\d+\)$/.exec(stackLine)[1];
return require.main.filename === callerModuleName;
};
Save this as is-main-module.js and now you can do:
const isMainModule = require("./is-main-module");
if (isMainModule()) {
console.info("called directly");
} else {
console.info("required as a module");
}
Which is easier to remember.
First, let's define the problem better. My assumption is that what you are really looking for is whether your script owns process.argv (i.e. whether your script is responsible for processing process.argv). With this assumption in mind, the code and tests below are accurate.
module.parent works excellently, but it is deprecated for good reasons (a module might have multiple parents, in which case module.parent only represents the first parent), so use the following future-proof condition to cover all cases:
if (
typeof process === 'object' && process && process.argv
&& (
(
typeof module === 'object' && module
&& (
!module.parent
|| require.main === module
|| (process.mainModule && process.mainModule.filename === __filename)
|| (__filename === "[stdin]" && __dirname === ".")
)
)
|| (
typeof document === "object"
&& (function() {
var scripts = document.getElementsByTagName("script");
try { // in case we are in a special environment without path
var normalize = require("path").normalize;
for (var i=0,len=scripts.length|0; i < len; i=i+1|0)
if (normalize(scripts[i].src.replace(/^file:/i,"")) === __filename)
return true;
} catch(e) {}
})()
)
)
) {
// this module is top-level and invoked directly by the CLI
console.log("Invoked from CLI");
} else {
console.log("Not invoked from CLI");
}
It works correctly in all of the scripts in all of the following cases and never throws any errors†:
Requiring the script (e.x. require('./main.js'))
Directly invoking the script (e.x. nodejs cli.js)
Preloading another script (e.x. nodejs -r main.js cli.js)
Piping into node CLI (e.x. cat cli.js | nodejs)
Piping with preloading (e.x. cat cli.js | nodejs -r main.js)
In workers (e.x. new Worker('./worker.js'))
In evaled workers (e.x. new Worker('if (<test for CLI>) ...', {eval: true}))
Inside ES6 modules (e.x. nodejs --experimental-modules cli-es6.js)
Modules with preload (e.x. nodejs --experimental-modules -r main-es6.js cli-es6.js)
Piped ES6 modules (e.x. cat cli-es6.js | nodejs --experimental-modules)
Pipe+preload module (e.x. cat cli-es6.js | nodejs --experimental-modules -r main-es6.js)
In the browser (in which case, CLI is false because there is no process.argv)
In mixed browser+server environments (e.x. ElectronJS, in which case both inline scripts and all modules loaded via <script> tags are considered CLI)
The only case where is does not work is when you preload the top-level script (e.x. nodejs -r cli.js cli.js). This problem cannot be solved by piping (e.x. cat cli.js | nodejs -r cli.js) because that executes the script twice (once as a required module and once as top-level). I do not believe there is any possible fix for this because there is no way to know what the main script will be from inside a preloaded script.
† Theoretically, errors might be thrown from inside of a getter for an object (e.x. if someone were crazy enough to do Object.defineProperty(globalThis, "process", { get(){throw 0} });), however this will never happen under default circumstances for the properties used in the code snippet in any environment.
How can I detect whether my node.js file was called directly from console (windows and unix systems) or loaded using the ESM module import ( import {foo} from 'bar.js')
Such functionality is not exposed. For the moment you should separate your cli and library logic into separate files.
Answer from node.js core contributor devsnek replying to nodejs/help/issues/2420
It's the right answer in my point of view