I'm experiencing incomplete support for RequireJS when using PhpStorm. Dependencies are acknowledged, but the IDE is unable to resolve the dependency interface, resulting in a ton of unresolved function or method warnings for example. Am I doing something wrong, or missing something?
For example:
//Foo.js
define(() => {
function Foo() {}
Foo.prototype.bar = function () {
return true;
}
return Foo;
});
//Baz.js
define([
'Foo' // PhpStorm does acknowledge the Foo.js dependency, referring to the appropriate file
], (Foo) => {
let foo = new Foo();
console.log(foo.bar()); // But is not aware that Foo.prototype.bar exists, and generates a warning
});
I'm hesitant to refactor this code into something like export default Foo; (which has better support) just to enable better IDE support, as I feel I might be doing something wrong, or missing some sort of plugin.
Is there anything I can do to improve this?
If you have a package.json and don't have requirejs specified in the dependencies section, please, install it:
npm i --save requirejs
That definitely could help.
With the exact same setup for a fresh project, the IDE was working as expected. So it turns out the project specific IDE settings (or cache?) caused the problem. Invalidating the cache didn't solve it, but removing the .idea/ folder (and letting it be recreated) did.
Related
I am working in a commonjs environment trying to dynamically import an es module
Consider the below code :
const mysqlController = (async function () {
try{
var {default:dateformat}= await import('dateformat');
// also tried await import('../../../node_modules/dateformat/lib/dateformat.mjs')
}
catch(e){
console.error('Line 31 of db_controller');
console.error(e);
}
// More stuff
})()
The statement await import('dateformat'); works fine when debugging. But when using pkg to produce a standalone executable, it gives the following error:
TypeError: Invalid host defined options
Could somebody tell me what is going on here?
Okay, for some reason node executables made with package pkg doesn't honor import() statements.
As a temporary workaround, I made cjs alternatives for the es modules which I was trying to import using rollup.
Then, I copied the bundle locally and required those.
Vercel/pkg does not (yet) support import of ES6 modules.
The reason seems to be that pkg must traverse all require()-calls in your program to know what exactly needs to be packaged together into the exe it creates. It does not know it should do a similar thing with all and any import-statements in your program as well.
SEE: https://github.com/vercel/pkg/pull/1323
I'm trying to begin using Flowtype but when importing sub packages, e.g.
import isArray from 'lodash/isArray';
my eslint is complaining that the required module not found.
I already used flow-typed install to install all lib defs that can be found.
Any idea on how to tackle this?
Thanks!
Flow is treating lodash/isArray as it's own module so it needs to be told what the exports of that module are.
Modify the lodash libdef to export lodash/isArray also.
You can do this like this (I extracted out a subset of the libdef and showed you what would need to change)
declare module 'lodash/isArray' {
declare function isArray(value: any): bool;
declare module.exports: typeof isArray
}
declare module 'lodash' {
declare class Lodash {
isArray: $Exports<'lodash/isArray'>
}
declare var exports: Lodash;
}
Let me know if you have any questions.
If it's normal for people to load lodash modules the way you're doing it, the whole libdef should be updated to support this use case.
First, Flow is not ESLint. They are two separate tools. flow-typed install will typically not affect ESLint errors.
Based on the information in your question, I see two possiblities:
You haven't actually installed lodash. Make sure it is listed as a dependency in your package.json and run npm install.
You are somehow piping Flow errors through ESLint (though I do not recommend this), and there is an issue with the flow-typed libdef for lodash. In that case you will likely need to figure out how to tweak the libdef to allow this.
I am not exactly a node newbie, but this issue has me stumped. Basically, this is an issue for me, nobody else on my team. After the usual npm install etc, calling a function returns require(...) is not a function. I have exported it properly and am passing in the parameter properly and again, this seems to be limited to me. Any suggestions?
Function file
const logger = require('../util/logger')('someParam');
^Fails here
Logger file:
function logger(param) {
console.log('this is the param: ', param);
}
module.exports = logger;
I have tried this in node 4.4.2, 6.10.2 and 7.7.1
I forgot about this question. After some time, I decided to reclone the repo and npm install again, and the issue did not present itself. I have no idea what caused the issue as my code was the same as a fresh clone. One of those things.
I'm working on a library for node.js that is build primarily as a native module. As such, when people try to include it in node-webkit projects, they have to recompile it using nw-gyp instead of node-gyp. I know we can detect node-webkit specifically when our built code runs using something like this:
try {
isNodeWebkit = (typeof require('nw.gui') !== "undefined");
} catch(e) {
isNodeWebkit = false;
}
However, I would like to detect this inside of our install script (run by npm install). Alternatively, we look in our own package.json, but is there maybe a way to look at the root project's package.json? That way we could at least look at some property, maybe engine or something?
In order to look into your own package.json you can do something like this
gui = require(nw.gui);
myPackageJSONFile = gui.App.manifest; // this will get the package.json file
I hope this helps.
I ended up writing a module to do this: https://github.com/maxkorp/which-native-nodish (also supports atom-shell and the renamed nw.js)
The gist is that you start at the parent directory to the module, and keep going up as long as you are a child of a node_modules folder which is a child of a folder with a package.json. Once at the root level, check the engines property in the package.json for an atom-shell, node-webkit or nwjs property. Not guaranteed to work (The farthest ancestor project must specify if its using a node-ish engine in this way), but it's better than nothing, and the only out of the box solution I've seen.
Simply as this:
isNodeWebkit = (typeof process == "object");
So, armed with this tutorial, I decided to add some unit testing to my node.js app. My gruntfile seems to be OK, and when I type grunt nodeunit my only test runs just fine, but after that, it crashes with error Fatal error: Cannot find module 'tap':
$> grunt nodeunit
Running "nodeunit:all" (nodeunit) task
Testing db.test.js
.OK
Fatal error: Cannot find module 'tap'
I didn't know anything about this module, but after googliing it up, it seemed that it's something nodeunit would require. And indeed, there it is: $MY_NODE_APP/node_modules/nodeunit/node_modules/tap exists, and when I launch node in $MY_NODE_APP/node_modules/nodeunit and type require('tap') in interactive console, I get some object with a lot of stuff that gives me an impression that it works as it should.
So, the obvious question: why do I get this error, and how can I fix it?
Gruntfile:
module.exports = function(grunt) {
grunt.initConfig({
nodeunit: {
all: ['./**/*.test.js']
}
});
grunt.loadNpmTasks('grunt-contrib-nodeunit');
};
Update: Installed tap to my project, but it didn't help too.
I landed on this question and have since resolved my own issue. I'll post my resolution as it might be helpful to someone else:
First the similarities:
I was just getting my Gulp scripts setup, and I got this error when running my tests:
Fatal error: Cannot find module 'tap'
Which didn't make sense because I wasn't using that library!
How I resolved:
Turns out my paths were all kind of screwed up in my gulpfile.js. Therefore I was trying to unit test all of the modules in my node_modules folder!
Here's the new path:
paths: {
mocha: [
'**/*.test.js',
'!node_modules/**/*.js'
]
}
The issue for me was that I was inadvertently running the tests within the node_modules directory. My npm test was mocha **/*.test.js and when I changed it to mocha src/**/*.test.js all of a sudden the message went away. Makes sense really.
I have solved the problem by adding another '*' right after "mocha" it is related to the folder's path so it may also fix the problem in other cases.
I solved the issue (well, this issue — it wasn't the last one) by installing the tap module manually.