search

pionxzh / wakaru

🔪📦 Javascript decompiler for modern frontend
https://wakaru.vercel.app/
MIT License
244 stars 12 forks source link

Dynamic require of "assert" is not supported Error when importing Wakaru Unpacker #134

Open Acters opened 1 month ago

Acters commented 1 month ago

Hello, I tried to add the Wakaru unpacker however, it seems that there is a problem. I created a separate local environment to only install wakaru unpacker and unminify as stated in the API section: npm install @wakaru/unpacker @wakaru/unminify I, then, added type: "module", to package.json that was created, because it would throw SyntaxError: Cannot use import statement outside a module

All I have in the index.js file is import { unpack } from '@wakaru/unpacker'; There is something awefully wrong in with importing the package.

This seemingly odd error that I just can't figure out on my own: 

file:///home/test/Documents/Github/humanify-ng/node_modules/@wakaru/unpacker/dist/index.js:12
  throw Error('Dynamic require of "' + x + '" is not supported');
        ^

Error: Dynamic require of "assert" is not supported
    at file:///home/test/Documents/Github/humanify-ng/node_modules/@wakaru/unpacker/dist/index.js:12:9
    at ../../node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/src/Collection.js (/home/test/Documents/Github/humanify-ng/node_modules/node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/src/Collection.js:11:16)
    at __require2 (file:///home/test/Documents/Github/humanify-ng/node_modules/@wakaru/unpacker/dist/index.js:18:50)
    at ../../node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/src/core.js (/home/test/Documents/Github/humanify-ng/node_modules/node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/src/core.js:10:20)
    at __require2 (file:///home/test/Documents/Github/humanify-ng/node_modules/@wakaru/unpacker/dist/index.js:18:50)
    at ../../node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/index.js (/home/test/Documents/Github/humanify-ng/node_modules/node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/index.js:9:18)
    at __require2 (file:///home/test/Documents/Github/humanify-ng/node_modules/@wakaru/unpacker/dist/index.js:18:50)
    at <anonymous> (/home/test/Documents/Github/humanify-ng/node_modules/@wakaru/shared/src/jscodeshift.ts:1:25)
    at ModuleJob.run (node:internal/modules/esm/module_job:195:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:337:24)

Node.js v18.20.4
pionxzh commented 1 month ago

I noticed a few issues:

  1. The ESM build does not work in simple Node.js environment. (node index.js)
  2. Running wakaru with tools like tsx works fine.
  3. Running wakaru with CJS works fine.
  4. The generated .d.ts is not valid. Typescript are not happy about it.
Acters commented 1 month ago

I noticed a few issues:

1. The ESM build does not work in simple Node.js environment. (`node index.js`)

2. Running wakaru with tools like `tsx` works fine.

3. Running wakaru with CJS works fine.

4. The generated `.d.ts` is not valid. Typescript are not happy about it.

Thank you for the reply. I will like to note I am using tsx to start the session.

package.json from the barebones install: 

{
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "tsx index.ts"
  },
  "type": "module",
  "dependencies": {
    "tsx": "^4.15.5",
    "@wakaru/unminify": "^0.2.2",
    "@wakaru/unpacker": "^0.1.2",
    "ts-node": "^10.9.2",
    "typescript": "^5.5.3"
  }
}

Same error output: 

# npm start           

> start
> tsx index.ts

file:///home/test/Documents/Github/TestWakaru/node_modules/@wakaru/unminify/dist/index.js:12
  throw Error('Dynamic require of "' + x + '" is not supported');
        ^

Error: Dynamic require of "assert" is not supported
    at file:///home/test/Documents/Github/TestWakaru/node_modules/@wakaru/unminify/dist/index.js:12:9
    at ../../node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/src/Collection.js (/home/test/Documents/Github/TestWakaru/node_modules/node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/src/Collection.js:11:16)
    at __require2 (file:///home/test/Documents/Github/TestWakaru/node_modules/@wakaru/unminify/dist/index.js:18:50)
    at ../../node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/src/core.js (/home/test/Documents/Github/TestWakaru/node_modules/node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/src/core.js:10:20)
    at __require2 (file:///home/test/Documents/Github/TestWakaru/node_modules/@wakaru/unminify/dist/index.js:18:50)
    at ../../node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/index.js (/home/test/Documents/Github/TestWakaru/node_modules/node_modules/.pnpm/jscodeshift@0.15.2_@babel+preset-env@7.23.9/node_modules/jscodeshift/index.js:9:18)
    at __require2 (file:///home/test/Documents/Github/TestWakaru/node_modules/@wakaru/unminify/dist/index.js:18:50)
    at <anonymous> (/home/test/Documents/Github/TestWakaru/node_modules/@wakaru/shared/src/jscodeshift.ts:1:25)
    at ModuleJob.run (node:internal/modules/esm/module_job:195:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:337:24)

Node.js v18.20.4
pionxzh commented 1 month ago

You are right. I think the ESM build is broken.

Acters commented 1 month ago

seems like a hot topic over in esbuild https://github.com/evanw/esbuild/issues/1921#issuecomment-1891102759 https://github.com/angular/angular-cli/issues/27994#issuecomment-2208591047

I do think that the issue is because of mixing commonjs with esm builds. Hope these can help you publish a fixed npm build. unfortunately the new Node 22 --experimental-require-module parameter (article link, documentation link) cannot be used in my project as some packages cannot support higher than Node 18 in my project, notably zeromq5 https://github.com/zeromq/zeromq.js/issues/551 when things are able to update to v22+ I think these issues can be a thing of the past.

Acters commented 1 month ago

Hello, I don't wish to annoy you. I made a band aid fix for my own testing environment while you are resolving this issue. In the index.js file for both ./node_modules/@wakaru/unminify and ./node_modules/@wakaru/unpacker, I simply replaced your __require variable with: 

import { createRequire } from 'node:module';
var __require = createRequire(import.meta.url);

so far not causing issues from what I can see, thank you.

pionxzh commented 1 month ago

I also saw that fix in esbuild's issue thread. Thanks for testing it out.

I'm working on rewriting the whole bundling process, using rollup.

I also noticed https://github.com/facebook/jscodeshift/issues/500 mentions

There is also the matter that jscodeshift in its current state is (as far as I'm aware) permanently incompatible with ESM.

Anyway, even though they might have other issues, I already have a plan to fork it to fix them.

0xdevalias commented 1 month ago

unfortunately the new Node 22 --experimental-require-module parameter (article link, documentation link) cannot be used in my project as some packages cannot support higher than Node 18 in my project, notably zeromq5 zeromq/zeromq.js#551 when things are able to update to v22+ I think these issues can be a thing of the past.

@Acters You might want to look at the zeromq v6 beta builds and see if they solve your issue; as there was another thread I was on recently where this seemed to be the best solution:

did anyone fix this?

@JxxIT I believe the solution is probably "use an older version of node that the zeromq.js binaries are built for"

And maybe when upstream releases v6 it will solve it more specifically:

Status update

Zeromq is in a much better status as of the recent release. We have prebuilt binaries for many platforms. Most of the tests are passing. The remaining failing tests are related to Proxies and some GC tests, which I don't consider a blocker. But I appreciate contributions. Given that curve security is optional upstream, we don't have issues regarding Libsodium for now. So we can probably go for the v6 release soon.

Originally posted by @aminya in https://github.com/zeromq/zeromq.js/issues/529#issuecomment-2174252859

So perhaps you could try one of the v6 betas (though there might be other breaking changes required to do so):

It looks like the latest version of node has been supported in the build scripts since v6.0.0-beta.9:

Or maybe even v6.0.0-beta.8:

Originally posted by @0xdevalias in https://github.com/jehna/humanify/issues/10#issuecomment-2227604810

@0xdevalias Wow, thanks! It worked for me.

Originally posted by @JxxIT in https://github.com/jehna/humanify/issues/10#issuecomment-2228069944

I recommend using the latest beta version of zeromq until we fully release v6

Originally posted by @aminya in https://github.com/jehna/humanify/issues/10#issuecomment-2228965447

pionxzh commented 1 month ago

Status update:

  1. I have rewritten the bundling process. It looks great. The only issue remaining is the generated type is still invalid.
  2. I have forked ast-types to avoid the quirk situation that we are patching a dependency of a dependency. https://github.com/pionxzh/ast-types-x
  3. I will fork jscodeshift with some adjustments, and use this forked ast-types
  4. With the introduction of these forked packages, we will not need to use workarounds on bundling/importing. Things get easier.