In the documentation for visionmedia's debug module for Node.js, I see that it is possible to enable and disable different debug targets programmatically.
My attempts to do this have not been very successful.
I created a barebones script: test.js
const debug = require("debug");
let test = debug("test"); // created before being enabled
console.log(1, debug.enabled("test"));
let namespaces = debug.enable("test");
// test = debug("test");
console.log(2, debug.enabled("test"));
console.log("enabled namespaces:", namespaces);
test("this is test");
namespaces = debug.disable();
// test = debug("test");
console.log(3, debug.enabled("test"));
console.log("disabled namespaces:", namespaces);
test("you shouldn't see this");
When I run the script using node test.js, I get the following output, which shows that debug.enable("test") has neither enabled the test debug target, nor has it returned any namespaces:
1 false
2 true
enabled namespaces: undefined
3 false
disabled namespaces: undefined
When I run the script using DEBUG=test node test.js, I get the following output, which shows that debug.disable("test") has neither disabled the test debug target, nor has it returned the names of any disabled namespaces:
1 true
2 true
enabled namespaces: undefined
test this is test +0ms
3 false
disabled namespaces: undefined
test you shouldn't see this +0ms
However, if I uncomment the lines that recreate the test debug target after using .enable() or .disable(), then everything works.
It seems that, in order to be able to enable and disable debug targets programatically, I need to use a different syntax:
debug("test")("message which can be enabled or disabled");
But it seems that this creates a new debug instance each time it is used, which would be wasteful. And it is not the standard syntax described in the documentation. And, even so, the .enabled() and .disabled() methods do not return a list of namespaces.
Is there something that I have badly misunderstood?
The issue was caused because I was relying a version of debug installed as a dependency for express. It turns out that the current version of express requires an outdated version of debug.
After running npm install express today (27 June 2021), the entry for debug in package-lock.json was as follows.
"debug": {
"version": "2.6.9",
"resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz",
"integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==",
"requires": {
"ms": "2.0.0"
}
"version": "2.6.9"
(This is version "4.17.1" of express.)
This is because the package.json file for express explicitly calls for "debug": "2.6.9".
Running npm update has no effect on this.
Running npm install debug does fix the problem. The entry for debug in package-lock.json gets set to the following:
"debug": {
"version": "4.3.1",
"resolved": "https://registry.npmjs.org/debug/-/debug-4.3.1.tgz",
"integrity": "sha512-doEwdvm4PCeK4K3RQN2ZC2BYUBaxwLARCqZmMjtF8a51J2Rb0xpVloFRnCODwqjpwnAoao4pelN8l3RJdv3gRQ==",
"requires": {
"ms": "2.1.2"
}
"version": "4.3.1"
Problem solved.
Related
I'm writing an Express v4.18.2 app on Node.js 18.12.1 on Windows. I'm testing a controller with Jasmine 4.5.0. When I run jasmine spec, it fails with an error message about resolving ES modules:
Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import
'...\SimpleServiceJasmine\spec' is not supported resolving ES modules
imported from
...\SimpleServiceJasmine\node_modules\jasmine\lib\loader.js
...
code: 'ERR_UNSUPPORTED_DIR_IMPORT',
url: 'file:///D:/.../SimpleServiceJasmine/spec'
I use require, not import, everywhere in the code being tested or the spec.
Note that jasmine runs fine if I specify the spec file explicitly, even with wildcards, as long as the wildcard path resolves to a single file:
jasmine spec/service/contact-api.spec.js # ok
jasmine spec/*/c* # ok
I tried downgrading jasmine to 3.0.0 and 2.0.1 but got the same error. The behavior is the same on Windows 11 and Windows Server 2019.
Any suggestions for how can I run all the specs in this project?
Here's my package.json:
{
"name": "simpleservice",
"version": "1.0.0",
"description": "A simple CRUD API for contacts",
"main": "service/contact-api.js",
"scripts": {
"test": "jasmine spec/service/contact-api.spec.js",
"start": "node src/service/contact-api.js"
},
"author": "Puzzled Dev",
"license": "ISC",
"dependencies": {
"express": "^4.18.2"
},
"devDependencies": {
"jasmine": "^4.5.0"
}
}
Here's the spec/support/jasmine.json:
{
"spec_dir": "spec",
"spec_files": [
"**/*[sS]pec.?(m)js"
],
"helpers": [
"helpers/**/*.?(m)js"
],
"env": {
"stopSpecOnExpectationFailure": false,
"random": true
}
}
Jasmine uses glob for pattern matching, which means whenever you pass spec as a pattern, glob finds this particular directory and then returns it to jasmine. Unfortunately, path validation in jasmine does not seem in a very smart way, it continues executing with the given path, and then it throws an error by Node.js.
It is equivalent to this:
import spec from './spec'
You can take a look at the jasmine-runner code, and the line in which contributor put a comment:
The ES module spec requires import paths to be valid URLs. As of v14,
Node enforces this on Windows but not on other OSes. On OS X, import
paths that are URLs must not contain parent directory references.
So, once you have defined spec_files in jasmine.json, there is no need to give an extra pattern to execute all tests.
jasmine will execute all tests with the help of spec_dir, and spec_files fields in jasmine.json. All you need to do is just simply run jasmine or npx jasmine.
I am getting some confusing warnings when building a backend Node server with Webpack. I want to use Webpack to build my backend primarily for two reasons:
Webpack creates a single executable file, which is easier to deploy
Webpack includes all of my app's dependencies, so I can deploy my app to any compatible Node environment without needing to install dependencies first
Here are the warnings I'm getting:
WARNING in ./~/ws/lib/BufferUtil.js
Module not found: Error: Can't resolve 'bufferutil' in .../node_modules/ws/lib
# ./~/ws/lib/BufferUtil.js 35:21-42
# ./~/ws/lib/Receiver.js
# ./~/ws/index.js
# ./src/main.js
WARNING in ./~/ws/lib/Validation.js
Module not found: Error: Can't resolve 'utf-8-validate' in .../node_modules/ws/lib
# ./~/ws/lib/Validation.js 10:22-47
# ./~/ws/lib/Receiver.js
# ./~/ws/index.js
# ./src/main.js
WARNING in ./~/express/lib/view.js
80:29-41 Critical dependency: the request of a dependency is an expression
For the Critical dependency warning, I've found a good example explaining the problem and some documentation on how to use the ContextReplacementPlugin, although it's still unclear to me how to apply it to this situation. It looks like the warning is being caused by line 80 in node_modules/express/lib/view.js:
opts.engines[this.ext] = require(mod).__express
It is clear to me that the dependency cannot be resolved at build time, so how can I use the ContextReplacementPlugin to fix this dependency?
As for the Module not found warnings in the ws package, it's unclear to me what's going on. It looks like those dependencies exist in my global node_modules, and maybe they're not being pulled in by Webpack. I've tried adding them to my project's devDependencies, but then I just get Critical dependency warnings for them instead.
My application still runs after being built, so I suppose I could technically ignore the warnings, but I figure that these are widely used Node packages and Webpack is a popular build tool, so there must be a reasonable solution available.
Here are my dependencies in my package.json:
"devDependencies": {
"#types/cassandra-driver": "^0.8.10",
"#types/express": "^4.0.35",
"#types/uuid": "^2.0.29",
"#types/ws": "0.0.40",
"nodemon": "^1.11.0",
"typescript": "^2.3.1",
"webpack": "^2.5.1"
},
"dependencies": {
"cassandra-driver": "^3.2.1",
"express": "^4.15.2",
"uuid": "^3.0.1",
"ws": "^2.3.1"
}
And here's my webpack.config.js:
const path = require('path');
module.exports = {
entry: './src/main.js',
output: {
path: path.join(__dirname, 'dist'),
filename: 'main.js'
},
target: 'node',
node: {
__dirname: false,
__filename: false
}
};
I like keeping things minimal if possible. Thanks for reading.
The short answer
webpack can work with node, but it cannot extract follow require() statements. Modifications have to be made to ignore require() in order for it to work.
The long answer
It is actually possible to pull some files into a master file and run it in some instances.
One instance is if all the modules required are written in typescript and the modules are written in a away that the typescript plugin can parse the module in.
Another instance would be if you are using es6 babel plugins and using es6 style imports.
Even in the above scenarios the blunder may choose not to pull in certain files
The ultimate answer
It really should not matter too much about trying to perform the long answer because modules are stored in memory at boot and then referenced later from the cache. See the article below for more information.
http://fredkschott.com/post/2014/06/require-and-the-module-system/
Trying to bundle the following file with Webpack fails with
ERROR in ./~/pg/lib/native/index.js Module not found: Error: Cannot
resolve module 'pg-native' in
.../node_modules/pg/lib/native
# ./~/pg/lib/native/index.js 9:13-33
I tried several ignore statements in the .babelrc but didnt get it running...
The test-file i want to bundle: handler.js
const Client = require('pg').Client;
console.log("done");
webpack.config.js
module.exports = {
entry: './handler.js',
target: 'node',
module: {
loaders: [{
test: /\.js$/,
loaders: ['babel'],
include: __dirname,
exclude: /node_modules/,
}]
}
};
.babelrc
{
"plugins": ["transform-runtime"],
"presets": ["es2015", "stage-1"]
}
package.json
"dependencies": {
"postgraphql": "^2.4.0",
"babel-runtime": "6.11.6"
},
"devDependencies": {
"babel-core": "^6.13.2",
"babel-loader": "^6.2.4",
"babel-plugin-transform-runtime": "^6.12.0",
"babel-preset-es2015": "^6.13.2",
"babel-preset-stage-0": "^6.5.0",
"babel-polyfill": "6.13.0",
"serverless-webpack": "^1.0.0-rc.3",
"webpack": "^1.13.1"
}
Somewhat related github-issues:
https://github.com/brianc/node-postgres/issues/1187
https://github.com/serverless/serverless-runtime-babel/issues/8
This is indeed an old thread, but one that helped me nonetheless.
The solution provided by Steve Schafer 1 is good, but not the simplest.
Instead, the one provided by Marco Lüthy 2 in the linked issue is probably the easiest to set up because it is pure configuration, without even the need for a dummy file to be created.
It consists of modifying your Webpack config plugins array as follows:
const webpack = require('webpack');
const webpackConfig = {
...
resolve: { ... },
plugins: [
new webpack.IgnorePlugin(/^pg-native$/)
// Or, for WebPack 4+:
new webpack.IgnorePlugin({ resourceRegExp: /^pg-native$/ })
],
output: { ... },
...
}
Updated to include a change suggested in the comments.
This is an old thread but the problem still exists, so for anyone experiencing it, there is a workaround. The problem is an interaction between the way that node-postgres is written and how babel rewrites the code, which forces pg-native to be loaded even when you don't explicitly import/require it.
The simplest workaround is to add a couple of aliases to your webpack.config.js to cause it to link in a dummy do-nothing file instead:
{
...
resolve: {
alias: {
...
'pg-native': path-to-dummy-js-file,
'dns': path-to-dummy-js-file
}
}
...
}
where the dummy file contains a single line:
export default null
See https://github.com/brianc/node-postgres/issues/838 for further discussion and alternative workarounds.
I know that this is an old topic but I'm compelled to share how I solved it. It was maddening to deal with.
So, here is the readers digest version as based on the recollection from the last brain cell that I have.
Error:
Webpack Compilation Error ./node_modules/pg/lib/native/client.js Module not found: Error: Can't resolve 'pg-native'
The error above was thrown when attempting to run a Cypress test that required the npm package 'pg'.
Attempting to install the pg-native package was not successful and resulted in another error; namely ->
Call to 'pg_config --libdir' returned exit status 1 while in binding.gyp. while trying to load binding.gyp
I found that executing pg_config --libdir in the VSCode cmd prompt resulted in that command failing.
However, I knew that it should work since running that command from the system command prompt resulted in this -> C:/PROGRA~1/POSTGR~1/9.3/lib
That is the path that contains a required dll.
So, instead of running npm install from the VSCode command prompt, I ran it from the command prompt as launched from windows.
The result...success!!! pg-native was installed successfully.
After, the Cypress test was able to run as well.
Errors in now way helped me to arrive at this solution. It was more just checking that things were installed that were required, etc.
You may have pg-native globally installed locally. Hence the packet manager does not include the pg-native in the lock file. That was a issue i experienced where it did run fine locally but every time i build in the cloud webpack complained about pg-native missing. I solved it by removing the lockfile in the files pushed to the cloud (In this case seed.run).
I am trying to run a node.js application that uses PouchDB (a local CouchDB implementation). I can run this successfully locally and even upload it and build it on my Bluemix instance. However, whenever I send a request to my app, I do not get a response and I see the following error in my Bluemix console:
[Error: Module version mismatch. Expected 46, got 14. This generally implies that leveldown was built with a different version of node than that which is running now. You may try fully removing and reinstalling PouchDB or leveldown to resolve.]
I have tried to add npm rebuild into my build pipeline above the npm install, which I can see does indeed do a rebuild. However, I still get the previous error.
A bit about my app: It is a bot for the Slack platform. A user sends a command and my Bluemix app then responds. My Bluemix app has multiple documents that PouchDB stores. As I say, all this runs and responds correctly on my development machine.
Here is my package.js for reference:
{
"name": "XXXXXXXXXXX",
"version": "0.x.0",
"description": "XXXXXXXXXXXX",
"main": "app.js",
"scripts": {
"start": "node app.js"
},
"repository": {
"type": "git",
"url": "XXXXXXXXXXX"
},
"keywords": [
"slack",
"bot",
"nodejs"
],
"author": "xxxxxxxxx",
"license": "MIT",
"dependencies": {
"bluebird": "^3.1.1",
"body-parser": "^1.14.2",
"cfenv": "^1.0.3",
"cheerio": "^0.19.0",
"express": "^4.13.3",
"pouchdb": "^5.1.0",
"request-promise": "^1.0.2"
},
"engines": {
"node": "^4.2.x",
"npm": "^2.14.x"
}
}
Also some additional history: I ran a prior version of my app on Bluemix when I was using MongoDB instead of PouchDB. My node version at the time was the default that Bluemix gave me when I started, which was version 0.12.x. However, this version didn't support arrow functions, which I make heavy use of now. Hence, the bump to node 4.2.x.
Thanks!
Edit: After some digging I found out that 'leveldown' (a dependency of PouchDB) makes use of npm prebuilds where available. What this means is that if a prebuild is available on their GitHub it will be downloaded instead of the source, as a convenience. Looking through the logs I notice that version 1.4.2 is being downloaded as the prebuild version through Bluemix. However, there is a version 1.4.3 available that looks like it solves my 'Expected 46, got 14` issue. So the new question is why is Bluemix doing this and how can I rectify it?
I tried to push on Bluemix the same version that you are using ("^5.1.0") in your package.json and it is working fine, even using node engine "4.0.x".
Moreover according to CF infrastructure, the runtime is build during application staging step, so the pouchdb module should be built with the right dependencies and references.
Have you tried to push your application again in order to force a full application restage?
If yes, the first step to understand what is going on is to get the application logs during the staging process and also as soon as this error message is returned.
So, on your terminal, run the following commands:
1 - cd into your source directory
2 - connect to Bluemix API
cf api https://api.[REGION].bluemix.net
where [REGION] is one of
eu-gb for United Kingdom
ng for US South
au-syd for Sydney
3 - Login to Bluemix and choose the right ORG and SPACE
cf login -u [BLUEMIX USERNAME]
cf target -o [BLUEMIX ORG] -s [BLUEMIX SPACE]
4 - push your application and, as soon as it has been staged, run
cf logs [app-name] --recent > staging_output.txt
5 - tail the application logs, running
cf logs [app-name]
and without closing it make the request that is generating the error message
6 - check the output generated at step #5 for details on where in the code your application is failing and on the failing module
After a lot of debugging the answer, as ever, was to delete my Bluemix application first and then push a new version via the build system. The leveldown prebuilt npm package that was causing the error was cached somewhere. I could only get rid of this by deleting my app. Nothing special there.
I am trying to get browserify-shim to work, but I can't seem to get it to create the globals I expect to see.
(note, my end goal is to get this working from gulp, but after having many problems, I figured I would eliminate one variable and try to get this working in browserify alone)
In this case, I expect "horses" to be created as a global variable pointing to the jQuery library.
// package.json
{
"version": "0.0.1",
"browser": {
"jquery": "./lib/js/vendor/jquery-2.0.2.js"
},
"browserify": {
"transform": [
"browserify-shim"
]
},
"browserify-shim": {
"jquery": "global:horses"
},
"devDependencies": {
// my dev dependencies
},
"dependencies": {
// my production dependencies
}
}
With this configuration, from the command line I run:
browserify common.js > mycoolfile.js
I then include mycoolfile.js into my application and run it in the browser:
<script src="mycoolfile.js"></script>
The browserified file is included fine, but when I go to chrome dev tools console and type "horses" I get an undefined error. Any thoughts on what I may be doing wrong? Thank you
I think that you want to get at jquery via exports and you are also assuming that global lets you take a global a module creates and make an alias for it, but I don't think it does that. The above might work if jquery really did have a global called horses it creates, but it won't if you just make up that name arbitrarily. I think you are trying to do something more like this:
"browserify-shim": {
"jquery": {"exports": "jQuery"}
},