I have some pre-ES6 code that was working fine with require-type syntax, and am trying to port this to ESM friendly methodology. I have much of the js to mjs coding ported, and am working on a dynamic file loading block, that is giving me fits. I've gotten through enough googling and debugging to realize my issue is now with the syntax of the export function in the "events" file, which I'm using default syntax to support.
First the calling file:
async function eventLoad(eventDir = './events/')
{
await fs.readdir(`./events/`,function (err, files){
if (err)
{
console.error(`${error}: Error loading event: ${err}`);
return;
}
else
{
const events = files.filter(file=>file.endsWith('.mjs'));
for( const file of events)
{
console.log(`event file name is ${file}`);
const {default: event} = import(join(`./events/`,`${file}`));
const eventName = file.split('.')[0];
dBot.on(eventName, event.bind(null,dBot));
console.log(`${success} Loaded event ${eventName}`);
}
}
})
}
eventLoad();
// please ignore the missing promise on the import...I'll be adding it shortly. :)
I get an error:
TypeError: Cannot read property 'bind' of undefined
my export in the other file declares like this:
export default async (client, message) =>
{
...
knowing from googled issues that much of the likelihood rests in the improper definition in the file that is exporting the fuction, I tried playing with the syntax:
async function ProcessMessages (client, message)
{
...
}
export {ProcessMessages as default };
but alas, no help. I'm sure the issue is properly handling the export syntax, but I'm learning this as I go, and would appreciate any help you could provide, thanks!!!
Update: (based on solution, here is my code changes in case anyone else wants to leverage)
async function eventLoad(eventDir = './events/')
{
let files;
try {
files = await promiseBasedReaddir(`${eventDir}`);
}
catch (err) {
console.error(`${error}: Error loading event: ${err}`);
return;
}
const events = files.filter(file=>file.endsWith('.mjs'));
for( const file of events)
{
console.log(`event file name is ${file}`);
import(`${eventDir}${file}`)
.then(function( {default: event} ){
const eventName = file.split('.')[0];
dBot.on(eventName, event.bind(null,dBot));
console.log(`${success} Loaded event ${eventName}`);
})
.catch(function(err){
console.error(`${error}: Error loading event: ${err}`);
return;
})
}
}
eventLoad();
On this line, you do a dynamic import:
const {default: event} = import(join(`./events/`,`${file}`));
import will always return a Promise. The Promise object doesn't have a .bind method, only functions do. You need to await or .then() import()'s return value. So you can't "ignore the missing promise on the import".
A second issue:
await fs.readdir(`./events/`, ...´
fs.readdir doesn't return a promise, so await-ing it is useless. It is functionally the same as await undefined;. The outer function will return before the callback has finished.
If you use a readdir function that returns a promise, you can simplify things a lot.
import { promises as fsPromises } from 'fs';
const { readdir: promiseBasedReaddir } = fsPromises;
// OR alternatively:
import { readdir } from 'fs';
import { promisify} from 'util';
const promiseBasedReaddir = promisify(readdir);
async function eventLoad(eventDir = './events/')
{
let files;
try {
files = await promiseBasedReaddir(`./events/`);
} catch (err) {
console.error(`${error}: Error loading event: ${err}`);
return;
}
const events = files.filter(file=>file.endsWith('.mjs'));
for( const file of events)
{
console.log(`event file name is ${file}`);
const {default: event} = await import(join(`./events/`,`${file}`));
const eventName = file.split('.')[0];
dBot.on(eventName, event.bind(null,dBot));
console.log(`${success} Loaded event ${eventName}`);
}
}
Promisify will transform a callback-using function to a promise-returning function. The fs module has promise-based functions, so you don't need to use Promisify if you just import those.
Related
Inside the /public/images directory of my Nuxt 3 project, I have a number of images, which are spread out into multiple sub-directories. For a gallery page, I want to read all file paths so that I can render an img tag for each one and don't have to hard-code them. Currently, I do this inside an API endpoint. The code for that looks like this:
import { readdir, stat } from "node:fs";
import { join } from "node:path";
async function read(path, callback) {
let images = [];
readdir(path, (err, files) => {
if (err) {
throw err;
}
let i = 0;
(function next() {
if (i === files.length) {
return callback(images);
}
const file = join(path, files[i++]);
stat(file, (err, stats) => {
if (err) {
throw err;
}
if (stats.isDirectory()) {
read(file, (value) => {
images = images.concat(value);
next();
});
} else {
images.push(file);
next();
}
});
})();
});
}
export default defineEventHandler(async (_event) => {
return await new Promise((resolve, reject) => {
try {
read("./public/images/blog", (value) => {
resolve(value.map((value) => value.substring(6)));
});
} catch (error) {
reject(error);
}
});
});
What I would like to do instead is create this array containing all image paths at build time. From my understanding, this could be achieved using lifecycle hooks. However, I don't understand the documentation for this part of the framework. Can somebody point me in the right direction?
Edit: You can use an async runtimeConfig
nuxt.config.ts
import { getImages } from './imageHandler';
export default defineNuxtConfig(async () => {
return {
runtimeConfig: {
public: {
images: await getImages()
}
}
}
})
MyComponent.vue
<script setup lang="ts">
let config = useRuntimeConfig();
let images = config.public.images;
</script>
<template>
<img v-for="img in images" :src="img" />
</template>
Note: If you use TypeScript the compiler will complain but the code should run. Use type any for the function to silence the compiler. There are no type declarations because this an undocumented deprecated feature that only exists for backwards compatibility with nuxt 2
Note 2: If you're on a nuxt 3 version that doesn't have this feature (either because it hasn't been added yet or because it has already been removed), you can rewrite your filesystem calls to their synchronous counterparts (fs.readdirSync etc.) and still achieve the same functionality
Note 3: Use runtimeConfig if you only need the data on the server. Use runtimeConfig.public if you need it on the client as well.
See: https://github.com/nuxt/framework/pull/1612 for more info about async function as nuxt.config
See: https://nuxt.com/docs/migration/runtime-config#runtime-config for more info about runtimeConfig
Old answer
You can define a module and use the 'build:before' lifecycle hook to execute code at build time.
Read more about lifecycle hooks here: https://nuxt.com/docs/guide/going-further/hooks
See also: https://nuxt.com/docs/guide/going-further/modules
Although after you have obtained your array of images I'm not sure how you can reference that array from other parts of the code, but I hope this is enough to help you in the right direction.
modules/yourModule.ts
import { defineNuxtModule } from '#nuxt/kit'
export default defineNuxtModule({
setup(options, nuxt) {
nuxt.hook('build:before', async ()=>{
// read contents of public and get images
let images = [];
// do something with images
})
}
})
nuxt.config.ts
import { getProjects } from "./data"
import yourModule from "./modules/yourModule"
export default defineNuxtConfig({
modules: [
yourModule
]
})
I am unit testing (using jest) a function named "getTripDetails" (inside file trip.js) that calls another file "getTrace.js" from different module (which exports a function as shown below).
I want to mock the call of function "getTrace" while testing "getTripDetails" function.
file: trips.js
const gpsTrace = require("./gpsTrace");
getTripDetails = async(req, res)=>{
let gpsTraceRes = await gpsTrace(req.body, req.adToken)
//more code...
return {status:200};
}
file: getTrace.js
module.exports = async(payload, token) =>{
try {
//code
} catch (e) {
error(e)
throw new Error(e)
}
}
This is what i tried after reading the docs.
file: test.js
let ctrl = require("./trips");
describe("API -- testing", function () {
it("Trip details", async function () {
jest.mock('./gpsTrace');
const gpsTrace = require('./gpsTrace');
gpsTrace.mockImplementation(() => {});
gpsTrace();
await ctrl.getTripDetails({},{});
expect(response.status).to.eql(200);
});
});
It did not get mocked, instead it was calling the original implementation.
Any suggesstions?
You were pretty close! Here are the updated files with comments describing the changes:
gpsTrace.js
Added a console.log message. We won't see this in the test if the mock works successfully.
module.exports = async (payload, token) => {
try {
//code
console.log("You won't see me in the Jest test because of the mock implementation")
} catch (e) {
error(e)
throw new Error(e)
}
}
trips.js
You needed to export your code to be used in other modules. Seeing as you're calling ctrl.getTripDetails() in the test, it makes sense to export your getTripDetails() on an object at the bottom of the file.
const gpsTrace = require("./gpsTrace");
const getTripDetails = async (req, res) =>{
let gpsTraceRes = await gpsTrace(req.body, req.adToken)
//more code...
return { status:200 };
}
module.exports = {
getTripDetails,
}
gpsTrace.test.js
Make sure to import your modules at the top of the file. Remember that ctrl.getTripDetails({}, {}) calls gpsTrace internally, so no need to call it twice in your test. You also needed to save the response returned from getTripDetails into a variable to be able to compare it: const response = await ctrl.getTripDetails({}, {});.
// make sure your require statements go at the top of the module
const gpsTrace = require('./gpsTrace');
let ctrl = require("./trips");
jest.mock('./gpsTrace');
gpsTrace.mockImplementation(() => {});
describe("API -- testing", function () {
it("Trip details", async function () {
// ctrl.getTripDeals() calls your gpsTrace function internally, so no need to call it twice
// gpsTrace(); <-- can be removed
// you needed to save the returned response into a variable to be able to test it.
const response = await ctrl.getTripDetails({}, {});
expect(response.status).toEqual(200);
});
});
Result
After running the test it now successfully passes. Notice that we DO NOT see the console.log message in the gpsTrace function, which indicates our mockedImplementation of the function is working in the test script. 👍
I'm attempting to mock a call to a class instance function on an ES6 module being imported by the code under test. I've followed the progress of the ES6 support and eventually stumbled onto this PR https://github.com/facebook/jest/pull/10976 which mentioned that in 27.1.1 support for jest.unstable_mockModule was added. I upgraded my version of Jest to take advantage and while the test doesn't error, it also doesn't seem to actually mock the module either.
This is the module under test:
// src/Main.mjs
import Responder from './Responder.mjs'
import Notifier from './Notifier.mjs'
export default {
async fetch(request, environment, context) {
let response
try {
response = new Responder(request, environment, context).respond()
} catch (error) {
return new Notifier().notify(error)
}
return response
}
}
Here is the test:
// test/Main.test.mjs
import { jest } from '#jest/globals'
import main from '../src/Main.mjs'
describe('fetch', () => {
test('Notifies on error', async () => {
const mockNotify = jest.fn();
jest.unstable_mockModule('../src/Notifier.mjs', () => ({
notify: mockNotify
}))
const notifierMock = await import('../src/Notifier.mjs');
await main.fetch(null, null, null)
expect(mockNotify).toHaveBeenCalled()
})
})
I'm trying to mock the call to Notify to expect it to have been called and while this will run, it raises an exception from inside the Notifier.notify() that is supposed to be mocked, so it appears that it isn't being mocked at all.
What am I missing? Any help is much appreciated. 🙏
I believe it's because you're importing main at the start of the file. You need to do a dynamic import the same way as Notifier.mjs
// test/Main.test.mjs
import { jest } from '#jest/globals'
describe('fetch', () => {
test('Notifies on error', async () => {
const mockNotify = jest.fn();
jest.unstable_mockModule('../src/Notifier.mjs', () => ({
notify: mockNotify
}))
const notifierMock = await import('../src/Notifier.mjs');
const main = await import('../src/Main.mjs');
await main.fetch(null, null, null)
expect(mockNotify).toHaveBeenCalled()
})
})
I have a module, for the purposes of learning testing, that looks like this:
api.js
import axios from "axios";
const BASE_URL = "https://jsonplaceholder.typicode.com/";
const URI_USERS = 'users/';
export async function makeApiCall(uri) {
try {
const response = await axios(BASE_URL + uri);
return response.data;
} catch (err) {
throw err.message;
}
}
export async function fetchUsers() {
return makeApiCall(URI_USERS);
}
export async function fetchUser(id) {
return makeApiCall(URI_USERS + id);
}
export async function fetchUserStrings(...ids) {
const users = await Promise.all(ids.map(id => fetchUser(id)));
return users.map(user => parseUser(user));
}
export function parseUser(user) {
return `${user.name}:${user.username}`;
}
Pretty straight forward stuff.
Now I want to test that fetchUserStrings method, and to do that I want to mock/spy on both fetchUser and parseUser. At the same time - I don't want the behaviour of parseUser to stay mocked - for when I'm actually testing that.
I run in the problem that it seems that it is not possible to mock/spy on functions within the same module.
Here are the resources I've read about it:
How to mock a specific module function? Jest github issue. (100+ thumbs up).
where we're told:
Supporting the above by mocking a function after requiring a module is impossible in JavaScript – there is (almost) no way to retrieve the binding that foo refers to and modify it.
The way that jest-mock works is that it runs the module code in isolation and then retrieves the metadata of a module and creates mock functions. Again, in this case it won't have any way to modify the local binding of foo.
Refer to the functions via an object
The solution he proposes is ES5 - but the modern equivalent is described in this blog post:
https://luetkemj.github.io/170421/mocking-modules-in-jest/
Where, instead of calling my functions directly, I refer to them via an object like:
api.js
async function makeApiCall(uri) {
try {
const response = await axios(BASE_URL + uri);
return response.data;
} catch (err) {
throw err.message;
}
}
async function fetchUsers() {
return lib.makeApiCall(URI_USERS);
}
async function fetchUser(id) {
return lib.makeApiCall(URI_USERS + id);
}
async function fetchUserStrings(...ids) {
const users = await Promise.all(ids.map(id => lib.fetchUser(id)));
return users.map(user => lib.parseUser(user));
}
function parseUser(user) {
return `${user.name}:${user.username}`;
}
const lib = {
makeApiCall,
fetchUsers,
fetchUser,
fetchUserStrings,
parseUser
};
export default lib;
Other posts that suggest this solution:
https://groups.google.com/forum/#!topic/sinonjs/bPZYl6jjMdg
https://stackoverflow.com/a/45288360/1068446
And this one seems to be a variant of the same idea:
https://stackoverflow.com/a/47976589/1068446
Break the object into modules
An alternative, is that I would break my module up, such that I'm never calling functions directly within each other.
eg.
api.js
import axios from "axios";
const BASE_URL = "https://jsonplaceholder.typicode.com/";
export async function makeApiCall(uri) {
try {
const response = await axios(BASE_URL + uri);
return response.data;
} catch (err) {
throw err.message;
}
}
user-api.js
import {makeApiCall} from "./api";
export async function fetchUsers() {
return makeApiCall(URI_USERS);
}
export async function fetchUser(id) {
return makeApiCall(URI_USERS + id);
}
user-service.js
import {fetchUser} from "./user-api.js";
import {parseUser} from "./user-parser.js";
export async function fetchUserStrings(...ids) {
const users = await Promise.all(ids.map(id => lib.fetchUser(id)));
return ids.map(user => lib.parseUser(user));
}
user-parser.js
export function parseUser(user) {
return `${user.name}:${user.username}`;
}
And that way I can mock the dependency modules when I'm testing the dependant module, no worries.
But I'm not sure that breaking up the modules like this is even feasible - I imagine that there might be a circumstance where you have circular dependencies.
There are some alternatives:
Dependency injection in the function:
https://stackoverflow.com/a/47804180/1068446
This one looks ugly as though, imo.
Use babel-rewire plugin
https://stackoverflow.com/a/52725067/1068446
I have to admit - I haven't looked at this much.
Split your test into multiple files
Am investigating this one now.
My question: This is all quite a frustrating and fiddly way of testing - is there a standard, nice and easy, way people are writing unit tests in 2018, that specifically solve this issue?
As you've already discovered attempting to directly test an ES6 module is extremely painful. In your situation it sounds like you are transpiling the ES6 module rather than testing it directly, which would likely generate code that looks something like this:
async function makeApiCall(uri) {
...
}
module.exports.makeApiCall = makeApiCall;
Since the other methods are calling makeApiCall directly, rather than the export, even if you tried to mock the export nothing would happen. As it stands ES6 module exports are immutable, so even if you did not transpile the module you would likely still have issues.
Attaching everything to a "lib" object is probably the easiest way to get going, but it feels like a hack, not a solution. Alternatively using a library that can rewire the module is a potential solution, but its extremely hokey and in my opinion it smells. Usually when you're running into this type of code smell you have a design problem.
Splitting up the modules into tiny pieces feels like a poor mans dependency injection, and as you've stated you'll likely run into issues quickly. Real dependency injection is probably the most robust solution, but it's something you need to build from the ground up, it's not something that you can just plug into an existing project and expect to have things working immediately.
My suggestion? Create classes and use them for testing instead, then just make the module a thin wrapper over an instance of the class. Since you're using a class you'll always be referencing your method calls using a centralized object (the this object) which will allow you to mock out the things you need. Using a class will also give you an opportunity to inject data when you construct the class, giving you extremely fine grained control in your tests.
Let's refactor your api module to use a class:
import axios from 'axios';
export class ApiClient {
constructor({baseUrl, client}) {
this.baseUrl = baseUrl;
this.client = client;
}
async makeApiCall(uri) {
try {
const response = await this.client(`${this.baseUrl}${uri}`);
return response.data;
} catch (err) {
throw err.message;
}
}
async fetchUsers() {
return this.makeApiCall('/users');
}
async fetchUser(id) {
return this.makeApiCall(`/users/${id}`);
}
async fetchUserStrings(...ids) {
const users = await Promise.all(ids.map(id => this.fetchUser(id)));
return users.map(user => this.parseUser(user));
}
parseUser(user) {
return `${user.name}:${user.username}`;
}
}
export default new ApiClient({
url: "https://jsonplaceholder.typicode.com/",
client: axios
});
Now lets create some tests for the ApiClient class:
import {ApiClient} from './api';
describe('api tests', () => {
let api;
beforeEach(() => {
api = new ApiClient({
baseUrl: 'http://test.com',
client: jest.fn()
});
});
it('makeApiCall should use client', async () => {
const response = {data: []};
api.client.mockResolvedValue(response);
const value = await api.makeApiCall('/foo');
expect(api.client).toHaveBeenCalledWith('http://test.com/foo');
expect(value).toBe(response.data);
});
it('fetchUsers should call makeApiCall', async () => {
const value = [];
jest.spyOn(api, 'makeApiCall').mockResolvedValue(value);
const users = await api.fetchUsers();
expect(api.makeApiCall).toHaveBeenCalledWith('/users');
expect(users).toBe(value);
});
});
I should note that I have not tested if the provided code works, but hopefully the concept is clear enough.
I would like to export a class which initial state depends on a value returned from a Promise in another module i cannot modify.
Here's the code:
let e = true;
APromiseFromAnotherModule()
.then(value => return value;);
export default class E {
constructor() {
if (e) {
//...
} else {
//...
}
}
}
I also tried with async/await encapsulating the Promise into an async function like this:
let e = true;
getInitialValue = async () => {
return await APromiseFromAnotherModule()
.then(value => e = value;);
};
e = getInitialValue();
export default class E {
constructor() {
if (e) {
//...
} else {
//...
}
}
}
But it doesn't make sense because that one is an async function so obviously it doesn't work.
What am I missing?
module exports are done synchronously. So, they cannot depend upon the results of an asynchronous operation.
And, await only works inside a function. It doesn't actually block the containing function (the containing function returns a promise) so that won't help you make an async operation into a synchronous one either.
The usual ways to deal with a module that uses some async code in its setup is to either export a promise and have the calling code use .then() on the promise or to initialize the module with a constructor function that returns a promise.
The code is only pseudo code so it's hard to tell exactly what your real problem is to show you specific code for your situation.
As an example. If you want to export a class definition, but don't want the class definition used until some async code has completed, you can do something like this:
// do async initialization and keep promise
let e;
const p = APromiseFromAnotherModule().then(val => e = val);
class E {
constructor() {
if (e) {
//...
} else {
//...
}
}
};
// export constructor function
export default function() {
return p.then(e => {
// after async initialization is done, resolve with class E
return E;
});
}
The caller could then use it like this:
import init from 'myModule';
init().then(E => {
// put code here that uses E
}).catch(err => {
console.log(err);
// handle error here
});
This solves several issues:
Asynchronous initialization is started immediately upon module loading.
class E is not made available to the caller until the async initialization is done so it can't be used until its ready
The same class E is used for all users of the module
The async initialization is cached so it's only done once
Edit in 2023. Modern nodejs versions when using ESM modules have top level await so it is possible to await an asynchronous result before your exports.
I understand that #jfriend00's answer works fine, but in my case, there is not just one block of code that depends on the foreign async function's completion.
In my app, configuration loading is asynchronous, so the server must wait for the configs to load before starting. Since there are other files (like routes) that compose the server that also need access to the configs, I would have to reluctantly call .then() in each other file.
Here is how I was able to do it with require statements instead of export.
config.js
Module that can be required by other modules in order to gain access to the global configs.
module.exports.loadAllConfigs = async () => {
const appConfigs = await AsyncConfigLibrary.load();
module.exports.CONFIG = appConfigs;
};
server.js
Main file for Node application that makes use of other modules that require access to global configs.
const { loadAllConfigs } = require('./modules/config');
loadAllConfigs()
.then(() => {
const { CONFIG } = require('./modules/config');
/* import modules */
const auth = require('./modules/auth');
};
auth.js
Module used by server.js that requires access to configs.
const { CONFIG } = require('./config');
const cookieSecret = CONFIG.secretItem;
Therefore, as long as the CONFIG property is set in config.js before any of the other modules attempt to access it, that is, before the modules are require'd, then the single .then() in server.js is sufficient.