osapi fails to build (depends on noda)

[reetou]

Hello, I cannot deploy my backend lambda function because of strange error and I want to ask for your help if it's possible.

General issue is I'm using osapi for my s3 connections and stuff and this package works well while I'm working locally but since it's deployed backend sends 502 on any lambda where piece of code with requiring osapi is present.

I created a public deployment: https://zeit.co/kkz-zae/express/g081kykjq
and also GitHub repository to reproduce this:
https://github.com/reetou/now-reproduce-express

As far as I understand it cannot find some dependencies of osapi for some reason.

Hope you will help me or feed my interest why it happened at least.

[rauchg]

@reetou can you try bundling a simple function that you run through ncc that minimally reproduces?

npm i -g @zeit/ncc

https://github.com/zeit/ncc

[reetou]

@rauchg Of course, here it is: link to commit
Actually reproducing example is lying under s3 directory in repository

[reetou]

Here's output:

/Users/vladimirsinitsyn/git/express/dist/index.js:463
            throw ex;
            ^

Error: Cannot find module '/Users/vladimirsinitsyn/git/express/swift'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:594:15)
    at Function.Module._load (internal/modules/cjs/loader.js:520:25)
    at Module.require (internal/modules/cjs/loader.js:650:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.inRequire (/Users/vladimirsinitsyn/git/express/dist/index.js:457:15)
    at Object.857 (/Users/vladimirsinitsyn/git/express/dist/index.js:930:20)
    at __webpack_require__ (/Users/vladimirsinitsyn/git/express/dist/index.js:22:30)
    at Object.86 (/Users/vladimirsinitsyn/git/express/dist/index.js:136:15)
    at __webpack_require__ (/Users/vladimirsinitsyn/git/express/dist/index.js:22:30)
    at startup (/Users/vladimirsinitsyn/git/express/dist/index.js:36:19)

And probably problem lies here
osapi/index.js

const MODULE_REQUIRE = 1
    /* built-in */
    
    /* NPM */
    , noda = require('noda')
    , cloneObject = require('jinang/cloneObject')
    
    /* in-package */
    , s3 = noda.inRequire('s3')
    , swift = noda.inRequire('swift')
    ;

Looks like these noda.inRequire that were used in osapi to require certain files inside project were interpreted wrong or kind of.

/**
 * To require some sub module in same package with fixed subpath wherever the caller is located.
 *
 * @example
 * // PACKAGE_HOMEDIR/lib/index.js
 *
 * // PACKAGE_HOMEDIR/foo.js
 * noda.inRequire('lib');
 *
 * // PACKAGE_HOMEDIR/foo/bar.js
 * noda.inRequire('lib');
 *
 * @param {string} subpath sub module's path relative to the home directory of the package in which the caller is located.
 */
let inRequire = function(subpath, nullIfNotFound) {
    // Find home directory of the package in which the caller is located.
    let dirname = getCallerPackageDir();
    let pathname = path.join(dirname, subpath);

    let mod = null;
    try {
        mod = require(pathname);
    } catch (ex) {
        if (nullIfNotFound && ex.code === 'MODULE_NOT_FOUND') {
            mod = null;
        }
        else {
            throw ex;
        }
    }
    return mod;
};

Or by looking on code above I can think that noda.inRequire function tries to require file by subpath variable and since it's built with webpack path to dir is something like './' and it's just tries to find swift file or directory which is unavailable since code is built with ncc to a single node.js file.

[styfle]

@reetou Thanks for the bug report!

As you mentioned, the osapi package depends on noda which performs a dynamic require and ncc has trouble finding the required files during static analysis.

I moved this issue to the ncc repo for tracking purposes.

[guybedford]

The only way to support this really is through a special casing due to the indirect dynamic require. noda only has 188 downloads per week, which seems quite small to create a special case, but we could do it.

[reetou]

@guybedford Thanks for your response. I already rewrote this part of code with aws-sdk so this is no more the case for me.

[reetou]

Sorry, closed this by mistake.