I'm writing some code for Node.js and I'm currently using JSHint to check over my code. However, when I use the require function to import modules, it says:
'require' is not defined.
How can I suppress the warning?
"use strict";
var express = require('express');
var register = require('./routes/register');
jshint is not aware of node.js globals by default you need to inform it.
add this comment to the top:
/* jshint node: true */
We can set node as the global environment variable in JSHint's .jshintrc file
This option defines globals available when your code is running inside of the Node runtime environment. Node.js is a server-side JavaScript environment that uses an asynchronous event-driven model. This option also skips some warnings that make sense in the browser environments but don't make sense in Node such as file-level use strict pragmas and console.log statements.
For more info http://jshint.com/docs/options/#node
{
"node": true
}
Errors like 'require' is not defined, 'console' is not defined, 'module' is not defined won't show up any more
You can configure JSHint by adding "require" to the .jshintrc file. For instance:
{
"globals" : {
"require": false
}
}
Or you can define globals per specific file only by:
/* global require */
For more information about how to configure JSHint please read JSHint Documentation
I stumbled upon this answer and couldn't get anything to work in VSCode. I got this to work:
Open JSON Settings file using the Preferences: Open Settings (JSON) via the Command Palette Window (Ctrl-Shift-P).
Add this section into the settings.json file:
{
"jshint.options": {
"esversion": 8, // This gets rid of some other warnings
"node": true
}
}
Related
I've just started using eslint. I initialized it and started fixing problems it pointed out.
One problem, however, it shouldn't complain about:
const data = fs.readFileSync(path.join(__dirname, _FILENAME));
The error is:
error '__dirname' is not defined
I did some searching and found that when you add --experimental to the node command that __dirname is not defined. This, however, isn't the case for me. I'm not running node with the --experimental flag.
See these questions:
Alternative for __dirname in Node.js when using ES6 modules
__dirname is not defined in nodejs
This is happening because ESLint does not know that your code is supposed to be used in Node.js: __dirname is not defined in browsers and also not defined in ES modules. To tell ESLint that your code will run in Node.js as a CommonJS module, open your ESLint config and set node: true in the env section. If you are using .eslintrc.json:
{
"env": {
"node": true
}
}
There are also other ways to specify environments, they are explained in the related documentation.
I ran into the same. Adding this to .eslintrc.json fixed it for me:
"globals": {
"__dirname": true
}
Got the idea from this similar question about the process global: https://stackoverflow.com/a/56777068/936907
currently I am writing an App using
NodeJS v13.12.0
Jest 25.4.0
xmljs 0.3.2
typescript 3.8.3
ts-jest 25.4.0
This App should mimic a CalDAV Server. For this reason, I rely on the module xmljs, which is (after my research) the only module giving me a direct path method for finding properties in the XML.
In the node Container, the App runs fine without any errors. But When I start a test with Jest, the test fails with the error
ReferenceError: GLOBAL is not defined
at node_modules/xmljs/core.js:46:2
at Object.<anonymous> (node_modules/xmljs/core.js:176:3)
at node_modules/xmljs/XmlParser.js:3:11
at Object.<anonymous> (node_modules/xmljs/XmlParser.js:204:3)
I now know, that this error originates from the xmljs module trying to set the GLOBAL variable, which in NodeJS resolved to global. But this does not happen in jest.
My code works like following:
import XmlParser = require("xmljs");
/*
* data is the body of a PROPFIND request
*/
new XmlParser({ strict: true }).parseString(data, (err, xmlNode) => {
// omit err
xmlNode.path(["propfind", "prop"], true);
const propertiesObj: XmlNode[] = childs[0].children;
const properties: string[] = [];
Object.keys(propertiesObj).forEach(n => {
properties.push(n);
});
logger.silly("Returning properties: %O", properties);
});
Can anyone
Show me a module to use instead without requiring huge modifications of my code
Which supports a pure js implementation without using node-gyp (since it may be used on windows server)
Show me how to make a workaround in jest to spoof this GLOBAL variable being set in xmljs
I appreciate your help
You can set the value of GLOBAL in the setup of your tests. It seems that the GLOBAL variable is the deprecated form of the global in node.
In your jest.config.js file you can add a setup file through the setupFiles option:
module.exports = {
[...] // Other configurations
setupFiles: ['<rootDir>/define-deprecated-global.js']
};
And in the file define-deprecated-global you can define the GLOBAL variable as:
global.GLOBAL = global;
I try to import a node module inside an Angular 8 web worker, but get an compile error 'Cannot find module'. Anyone know how to solve this?
I created a new worker inside my electron project with ng generate web-worker app, like described in the above mentioned ng documentation.
All works fine until i add some import like path or fs-extra e.g.:
/// <reference lib="webworker" />
import * as path from 'path';
addEventListener('message', ({ data }) => {
console.log(path.resolve('/'))
const response = `worker response to ${data}`;
postMessage(response);
});
This import works fine in any other ts component but inside the web worker i get a compile error with this message e.g.
Error: app/app.worker.ts:3:23 - error TS2307: Cannot find module 'path'.
How can i fix this? Maybe i need some additional parameter in the generated tsconfig.worker.json?
To reproduce the error, run:
$ git clone https://github.com/hoefling/stackoverflow-57774039
$ cd stackoverflow-57774039
$ yarn build
Or check out the project's build log on Travis.
Note:
1) I only found this as a similar problem, but the answer handles only custom modules.
2) I tested the same import with a minimal electron seed which uses web workers and it worked, but this example uses plain java script without angular.
1. TypeScript error
As you've noticed the first error is a TypeScript error. Looking at the tsconfig.worker.json I've found that it sets types to an empty array:
{
"compilerOptions": {
"types": [],
// ...
}
// ...
}
Specifying types turns off the automatic inclusion of #types packages. Which is a problem in this case because path has its type definitions in #types/node.
So let's fix that by explicitly adding node to the types array:
{
"compilerOptions": {
"types": [
"node"
],
// ...
}
// ...
}
This fixes the TypeScript error, however trying to build again we're greeted with a very similar error. This time from Webpack directly.
2. Webpack error
ERROR in ./src/app/app.worker.ts (./node_modules/worker-plugin/dist/loader.js!./src/app/app.worker.ts)
Module build failed (from ./node_modules/worker-plugin/dist/loader.js):
ModuleNotFoundError: Module not found: Error: Can't resolve 'path' in './src/app'
To figure this one out we need to dig quite a lot deeper...
Why it works everywhere else
First it's important to understand why importing path works in all the other modules. Webpack has the concept of targets (web, node, etc). Webpack uses this target to decide which default options and plugins to use.
Ordinarily the target of a Angular application using #angular-devkit/build-angular:browser would be web. However in your case, the postinstall:electron script actually patches node_modules to change that:
postinstall.js (parts omitted for brevity)
const f_angular = 'node_modules/#angular-devkit/build-angular/src/angular-cli-files/models/webpack-configs/browser.js';
fs.readFile(f_angular, 'utf8', function (err, data) {
var result = data.replace(/target: "electron-renderer",/g, '');
var result = result.replace(/target: "web",/g, '');
var result = result.replace(/return \{/g, 'return {target: "electron-renderer",');
fs.writeFile(f_angular, result, 'utf8');
});
The target electron-renderer is treated by Webpack similarily to node. Especially interesting for us: It adds the NodeTargetPlugin by default.
What does that plugin do, you wonder? It adds all known built in Node.js modules as externals. When building the application, Webpack will not attempt to bundle externals. Instead they are resolved using require at runtime. This is what makes importing path work, even though it's not installed as a module known to Webpack.
Why it doesn't work for the worker
The worker is compiled separately using the WorkerPlugin. In their documentation they state:
By default, WorkerPlugin doesn't run any of your configured Webpack plugins when bundling worker code - this avoids running things like html-webpack-plugin twice. For cases where it's necessary to apply a plugin to Worker code, use the plugins option.
Looking at the usage of WorkerPlugin deep within #angular-devkit we see the following:
#angular-devkit/src/angular-cli-files/models/webpack-configs/worker.js (simplified)
new WorkerPlugin({
globalObject: false,
plugins: [
getTypescriptWorkerPlugin(wco, workerTsConfigPath)
],
})
As we can see it uses the plugins option, but only for a single plugin which is responsible for the TypeScript compilation. This way the default plugins, configured by Webpack, including NodeTargetPlugin get lost and are not used for the worker.
Solution
To fix this we have to modify the Webpack config. And to do that we'll use #angular-builders/custom-webpack. Go ahead and install that package.
Next, open angular.json and update projects > angular-electron > architect > build:
"build": {
"builder": "#angular-builders/custom-webpack:browser",
"options": {
"customWebpackConfig": {
"path": "./extra-webpack.config.js"
}
// existing options
}
}
Repeat the same for serve.
Now, create extra-webpack.config.js in the same directory as angular.json:
const WorkerPlugin = require('worker-plugin');
const NodeTargetPlugin = require('webpack/lib/node/NodeTargetPlugin');
module.exports = (config, options) => {
let workerPlugin = config.plugins.find(p => p instanceof WorkerPlugin);
if (workerPlugin) {
workerPlugin.options.plugins.push(new NodeTargetPlugin());
}
return config;
};
The file exports a function which will be called by #angular-builders/custom-webpack with the existing Webpack config object. We can then search all plugins for an instance of the WorkerPlugin and patch its options adding the NodeTargetPlugin.
I have a script that does some analysis on my source files and a part of that analysis is to require the file. Some of the files are in JSX format however and node does not understand this by default.
Is it possible to make it so that a file that looks like this:
function MyModule () {
return <div>hello</div>
}
module.exports = MyModule
is possible to require through require('./my-module')?
Use JSX as a template engine in Node
NPM Package : https://www.npmjs.com/package/jsx-node
To be able to simply require .jsx files, you need to tell Node what to do with them. Running the following code makes you able to require('./SomeFile.jsx'):
require('jsx-node').install({
replace: {
preact: 'jsx-node',
}
});
Warning:
This module is still in a very early phase. Any production use should be approached with caution.
For more Detail visit Link.
Can someone give an example on how to use jest globals?
{
...
"jest": {
"globals": {
"__DEV__": true,
}
}
...
}
Do I specify the globals in the package.json file or do I create a folder with a js file where the globals should be defined?
Thanks
Yep. You put the globals in the package.json. For example, here's an excerpt from the default react-native jest configuration:
"jest": {
"globals": {
"__DEV__": true,
"__RCTProfileIsProfiling": false
},
...
},
This will make the variables available globally when the tests are run.
A cleaner way to add globals would be to set "setupFiles": "<rootDir>/private/jest/setup.js" in package.json, and then create a setup.js file that sets global.__DEV__ = true.
This pattern is helpful for making 3rd party libraries available as globals to Jest tests as well (like Backbone, jQuery, lodash, etc.) - eg. global.Backbone = require('backbone'); and so on.
(Re-submitting this as an answer as it was previously just a comment under Michael Helvey's answer.)
For me using the Jest config file worked much better because it is a Javascript file itself so it gives full freedom:
After running jest --init in your folder, in the jest.config.js file Jest makes, scroll down to find:
// A set of global variables that need to be available in all test environments
// globals: {},
Uncomment the second line and put all your globals in there.
If you are using create-react-app, you must use the src/setupTests.js file instead of pointing to a file via setupFiles in the package.json file.
https://create-react-app.dev/docs/running-tests/#srcsetuptestsjs
In the src/setupTests.js file, you can define globals like so:
global.TIMEOUT = 3000;
To share object variables (not only primitives as with configuration's globals property), you can use the testEnvironment property.
More explanations here in Jest's Git