Browserified bundles use function named `require` causing false missing import reports.

[ryan-roemer]

From https://github.com/FormidableLabs/serverless-jetpack/issues/116#issuecomment-674876195, it looks like browserify will bundle code that uses the actual function name require to import the code in the bundle and is not meant to be the actual Node.js require. This is as opposed to webpack, which has the unambiguous __webpack_require__() function for the same thing.

So this creates a lot of false missing files. In the sanitize-html case, there's lodash and other deps bundled in that then run afoul with require()s of code that's actually in the bundle. See, e.g., https://unpkg.com/sanitize-html@1.27.3/dist/sanitize-html.js

Example

Looking at the source in https://unpkg.com/sanitize-html@1.27.3/dist/sanitize-html.js we have:

// Require apply from lodash
require('./_apply')

// Here's the mapping to internal browserify structure
{"./_apply":44}

// At 44, we see this chunk of code (which I've prettified a bit):
44: [
function(require,module,exports){/**
 * A faster alternative to `Function#apply`, this function invokes `func`
 * with the `this` binding of `thisArg` and the arguments of `args`.
 *
 * @private
 * @param {Function} func The function to invoke.
 * @param {*} thisArg The `this` binding of `func`.
 * @param {Array} args The arguments to invoke `func` with.
 * @returns {*} Returns the result of `func`.
 */
function apply(func,thisArg,args) {
  switch(args.length){
    case 0:return func.call(thisArg);
    case 1:return func.call(thisArg,args[0]);
    case 2:return func.call(thisArg,args[0],args[1]);
    case 3:return func.call(thisArg,args[0],args[1],args[2]);
  }
  return func.apply(thisArg,args);
}
module.exports=apply;
},{}]

... and it does look like that that is the real lodash apply code within sanitize-html bundle that you'd normally find here: https://unpkg.com/lodash@4.17.20/_apply.js. S

My guess is that all of the four dependencies specified at https://github.com/apostrophecms/sanitize-html/blob/main/package.json#L29-L32 are actually included in that browserified bundle and you should be fine. Upon spot checking, lodash and postcss appear.

Task

• [ ] Figure out if there's something programmatic we can do.
• [ ] Maybe provide a guide or documentation to help folks diagnose and handle

[dominics]

@ryan-roemer Thanks for picking this up and carding it properly for me

Really impressed by serverless-jetpack so far. While building 31 functions, we've gone from 9 minutes with serverless-webpack to less than 2 minutes with serverless-jetpack. So we're more than happy to run with workarounds for now!

[dominics]

sanitize-html have upgraded their build process: https://github.com/apostrophecms/sanitize-html/blob/main/CHANGELOG.md#backwards-compatibility-breaks - as of 2.0 it no longer requires any special tracing configuration and just works with jetpack :+1: