Dynamic import - import() - fails when the code is packaged into an executable

[panulogic]

What version of pkg are you using?

5.6.0

What version of Node.js are you using?

16.14.2

What operating system are you using?

Windows 10

What CPU architecture are you using?

x86_64,

What Node versions, OSs and CPU architectures are you building for?

the same as described

Describe the Bug

     await import (path)

where path is a .mjs -file and importing file is a .js -file
crashes with error-message
"TypeError: Invalid host defined options" .

There is no error when the code is run in development, only when the exe built by pkg is run.

SEE ALSO: https://stackoverflow.com/questions/69734757/dynamic-import-import-fails-when-the-code-is-packaged-into-an-executable

Expected Behavior

The exe should not crash when dynamically importing an ES6 module

To Reproduce

Import a .mjs file from inside a .js file and build code that executes that code inot an exe with pkg and run it.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label

[github-actions]

This issue is now closed due to inactivity, you can of course reopen or reference this issue if you see fit.

[NotWearingPants]

This is caused by a Node.js issue (nodejs/node#43663) which is caused by a V8 issue.
Once that's fixed, pkg just needs to copy these lines from Node.js into here in bootstrap.js.

As a workaround you can use --public --no-bytecode if you're okay with disclosing sources.

[RangerMauve]

Using --public --no-bytecode doesn't seem to help. Packages aren't being loaded in. Adding sources to scripts or assets manually doesn't help either.

Is there something else that can help?

[sp00x]

I apparently (at times I'm in full "I have no idea what I'm doing" mode navigating these ESM/CJS issues) managed to get around this by using rollup to transpile my EJS-based source to CJS and then using @rollup/plugin-node-resolve with nodeResolvePlugin({ resolveOnly: [ "module-name-here" ] }) to ensure the lazy-loaded ESM module was included.

[FujiwaraChoki]

I apparently (at times I'm in full "I have no idea what I'm doing" mode navigating these ESM/CJS issues) managed to get around this by using rollup to transpile my EJS-based source to CJS and then using @rollup/plugin-node-resolve with nodeResolvePlugin({ resolveOnly: [ "module-name-here" ] }) to ensure the lazy-loaded ESM module was included.

How did you do that? I'm having the same issue rn >:3

[sp00x]

@FujiwaraChoki -

How did you do that? I'm having the same issue rn >:3

My source is TypeScript but you should just be able to comment out the parts involving plugin-typescript - this is my
rollup.config.js file:

import tsPlugin  from "@rollup/plugin-typescript";
import commonjsPlugin from "@rollup/plugin-commonjs";
import nodeResolvePlugin from "@rollup/plugin-node-resolve";

const includeSourcemaps = false;
const includeDeclarations = false;

export default {

  input: 'src/index.ts',

  output: {
    file: 'dist-cjs/index.cjs',
    inlineDynamicImports: true,
    format: 'cjs',
    sourcemap: includeSourcemaps
  },

  plugins: [

    tsPlugin ({
      tsconfig: './tsconfig.json',
      sourceMap: includeSourcemaps,
      declaration: includeDeclarations
    }),

    commonjsPlugin(),

    nodeResolvePlugin({      

      browser: false,

      // https://github.com/rollup/plugins/tree/master/packages/node-resolve/#exportconditions
      exportConditions: [ 'node', 'default', 'module', 'import' ],  // we have to include 'node' first here, or else "file-type" fails (tries to use the 'browser' export, which does not have all methods)

      preferBuiltins: true,

      resolveOnly: [
        // have to list every ESM based or await import()'ed module here
        /^@sindresorhus/, // slugify
        "file-type",
        'passwd-user',
        // ...
      ]
    })

  ]
};

As you can see I had to list all the 3rd party NPM modules I was listing that is ESM, as otherwise things fail at some point.

When running pkg afterwards you will most likely get a bunch of errors about not being able to generate byte code, but apparently it doesn't affect anything for me, but to be able to silence those completely you'd have to bundle everything public, i.e. using --public --public-packages \"*\" --no-bytecode with pkg.

Again, I'm in "I am not 100% sure what I am doing but it worked for me 🤷‍♂️" territory here, so YMMV :)