在AWS Lambda中使用airtable.js模块时遭遇abort-controller依赖找不到的问题

I've run into this exact issue before with Airtable.js on Lambda—local testing works perfectly, but Lambda throws that frustrating module not found error. The root cause is usually related to how dependencies are packaged or structured for Lambda's runtime environment, not the Airtable code itself. Here's how to fix it:

1. Verify Your Deployment Package Structure (Direct Zip Method) #

If you're bundling your code and node_modules into a single zip:

• Make sure you run npm install airtable --save --production in your project root directory (not a subfolder). This ensures all production dependencies (including abort-controller) are installed correctly.
• When creating your zip, include your function code (e.g., index.js) and the entire node_modules directory at the same level. Lambda looks for modules in /var/task/node_modules, so if node_modules is nested inside another folder, it won't be found.
• Use this command to create your zip (from the project root):

  zip -r lambda-deploy.zip .
  

  Avoid using tools that exclude nested dependencies or flatten the node_modules structure incorrectly.

2. Fix Lambda Layer Structure #

If you're using a Lambda Layer for Airtable:

• Lambda requires Node.js layers to have a specific structure: the node_modules folder must live inside a nodejs directory. Here's how to build it correctly:
  1. Create a temporary folder (e.g., airtable-layer)
  2. Inside that folder, make a nodejs subdirectory
  3. Navigate to nodejs and run npm install airtable --save --production
  4. Go back to the airtable-layer folder and zip the nodejs directory:

     zip -r airtable-layer.zip nodejs/
     

  5. Upload this zip as a Lambda Layer and attach it to your function. This ensures Lambda can resolve the abort-controller dependency correctly from the layer's path.

3. Manual Workaround (If Above Methods Fail) #

In some cases, the abort-controller package's main entry point might not be resolved properly in Lambda's environment. You can force-load it before importing Airtable:

var AWS = require("aws-sdk");
AWS.config.update({ region: "eu-west-1" });

// Add this line to manually load abort-controller before Airtable
require('abort-controller/dist/abort-controller');

const Airtable = require('airtable');
const base = new Airtable({ apiKey: "xxxxx" }).base('yyyyy');

exports.handler = async(event) => {
    try {
        console.info('trying create');
        let records = await base('Base1').create([{
            "fields": {
                "Status": "Scored",
                "C1": "testing",
                "C2": "airtable",
                "C3": "api",
                "C4": "from",
                "C5": "node",
            }
        }]);
        console.info('completed create');
        let records_list = records.map(r => r.getId()).join(',');
        console.info(records_list);
        return ({statusCode: 200, body: JSON.stringify(records_list)});
    } catch (e) {
        console.error(e);
        return ({statusCode: 401, body: JSON.stringify(e)});
    }
}

Alternatively, try downgrading to a slightly older version of Airtable.js (e.g., 0.11.6)—this version has a more straightforward dependency chain that plays better with Lambda's runtime.

Why This Happens Locally vs. Lambda #

Your local Node.js environment handles module resolution more flexibly, traversing nested node_modules directories without issue. Lambda's runtime, however, relies on strict path resolution, and if dependencies are packaged with incorrect structure or missing files (like the abort-controller dist file), it throws the module not found error. The key is ensuring all nested dependencies are properly included and structured for Lambda's /var/task or layer paths.

内容的提问来源于stack exchange，提问作者jfrank