Analysis and Solutions for TypeError: require(...) is not a function in Node.js

Error Phenomenon and Background Analysis

During Node.js development, developers frequently encounter the runtime error TypeError: require(...) is not a function. This error typically occurs when attempting to invoke the return value of a require statement as a function, but the actual returned value is not of function type. Based on the error stack trace, the issue arises at the line require('./app/routes')(app, passport), indicating that the exported content of the ./app/routes module cannot be correctly recognized as a function.

Core Cause: Module Export Mechanism

Node.js's module system is based on the CommonJS specification, where each module defines its external interface through the module.exports object. When using the require function to load a module, it returns the module.exports object of that module. If developers expect the return value of require to be a callable function, the loaded module must assign a function to module.exports.

The correct way to export a function should be as follows:

module.exports = function(app, passport) {
    // Route configuration code
    app.get('/', function(req, res) {
        res.render('index.ejs');
    });
    
    app.get('/login', function(req, res) {
        res.render('login.ejs', { message: req.flash('loginMessage') });
    });
    
    // More route configurations...
};

With this configuration, require('./app/routes') will return a function, allowing direct invocation via require('./app/routes')(app, passport). If the module does not correctly export a function but instead exports other types of values (such as objects, strings, or undefined), the aforementioned error will occur.

Common Error Scenarios Analysis

Scenario 1: Incorrect Module Export Type

If the code in the ./app/routes module resembles the following form:

// Error example: exporting an object instead of a function
module.exports = {
    routes: function(app, passport) {
        // Route logic
    }
};

In this case, require('./app/routes') returns an object containing a routes property, not the function itself. The correct way to call it would be:

var routes = require('./app/routes');
routes.routes(app, passport);

Scenario 2: Circular Dependency Issues

Another common cause is circular dependencies between modules. When module A depends on module B, and module B also depends on module A, Node.js's module system detects this circular dependency and handles it specially. In such cases, one of the require calls might return null or an incompletely initialized module object.

Consider the following circular dependency scenario:

// moduleA.js
var moduleB = require('./moduleB');
module.exports = {
    funcA: function() {
        console.log('Function A');
        moduleB.funcB();
    }
};

// moduleB.js  
var moduleA = require('./moduleA');
module.exports = {
    funcB: function() {
        console.log('Function B');
        // Here, moduleA might not be fully initialized
    }
};

A common solution to circular dependencies is to extract shared code into a third module or redesign the module structure to avoid direct circular references.

Debugging and Verification Methods

Method 1: Check Export Content

When encountering the error, first verify the return type of the require statement:

var routesModule = require('./app/routes');
console.log('Module type:', typeof routesModule);
console.log('Module content:', routesModule);

If typeof routesModule does not return 'function', you need to check the export logic of the loaded module.

Method 2: Verify Module File Existence

Ensure that the ./app/routes file actually exists and the path is correct. Node.js throws a MODULE_NOT_FOUND error for non-existent module files, but sometimes path configuration issues might lead to loading the wrong module.

Additional Considerations: Semicolon Usage in Immediately Invoked Functions

In JavaScript, when an Immediately Invoked Function Expression (IIFE) follows a require statement closely, attention must be paid to semicolon usage. Consider the following code:

// Potentially error-prone写法
const fs = require('fs')

(() => {
    console.log('Immediately invoked function');
})()

Due to JavaScript's Automatic Semicolon Insertion (ASI) mechanism potentially failing to correctly interpret the code intent, it is advisable to explicitly add a semicolon after the require statement:

// Correct approach
const fs = require('fs');

(() => {
    console.log('Immediately invoked function');
})()

This preventive measure can avoid unexpected parsing errors caused by ASI.

Best Practices Recommendations

To prevent the require(...) is not a function error, it is recommended to follow these best practices:

1. Clarify Export Intentions: During the module design phase, clearly define the export type of each module. If it is a function module, ensure the function is directly exported.
2. Maintain Consistent Export Style: Keep a consistent module export style throughout the project, avoiding mixed use of different export methods.
3. Document Module Interfaces: Add clear comments for each module, explaining the type and usage of its exported content.
4. Avoid Circular Dependencies: Consider module dependency relationships during the architecture design phase and try to avoid circular dependencies.
5. Use TypeScript: For large projects, consider using TypeScript for better type checking and module management support.

Conclusion

The core of the TypeError: require(...) is not a function error lies in the mismatch between the module's exported content and the caller's expectations. By deeply understanding the mechanisms of Node.js's module system, carefully inspecting module export logic, and employing appropriate debugging methods, developers can effectively identify and resolve such issues. Additionally, adhering to good coding practices and architectural design principles can reduce the occurrence of such errors from the source.