Open Acters opened 1 month ago
I noticed a few issues:
node index.js
)tsx
works fine..d.ts
is not valid. Typescript are not happy about it.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
You are right. I think the ESM build is broken.
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.
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.
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.
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
:
- https://github.com/zeromq/zeromq.js/releases/tag/v6.0.0-beta.9
fix: fix the Win x86 prebuild script by @aminya in https://github.com/zeromq/zeromq.js/commit/e30b162286efaa56de239fc9454e9d7a5071d562
Or maybe even
v6.0.0-beta.8
:
- https://github.com/zeromq/zeromq.js/releases/tag/v6.0.0-beta.8
- feat: rewrite the build script by @aminya in https://github.com/zeromq/zeromq.js/pull/519
- feat: add support for macOS Arm + Windows 32 bit by @aminya in https://github.com/zeromq/zeromq.js/pull/522
- feat: improve the architecture handling the build system by @aminya in https://github.com/zeromq/zeromq.js/pull/522
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
Status update:
ast-types
to avoid the quirk situation that we are patching a dependency of a dependency.
https://github.com/pionxzh/ast-types-xjscodeshift
with some adjustments, and use this forked ast-types
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, addedtype: "module",
to package.json that was created, because it would throwSyntaxError: 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: