User feedback suggestions

[horacioh]

Hey Kyle!!

I just tried moduloze with unist-util-visit. very simple CJS module. and it worked perfectly!!

there are some suggestions I have in order to make ir more user friendly:

1. If the target user requires it, it would be nice to have a simple walkthrough on how to use this package: I find something like a guided tutorial very good for something like this: example

2. Better (and more accurate error messages: I was testing moduloze with a "what I remembered was a " CJS module, but it was not. I was getting a config error when the actual error was that the module where I was trying to transform, was a ESModule already 🤦‍♂️. I know this was a silly mistake by me, but if I was getting something else as an error, it could let myself to review the actual module, and not the moduloze config.

3. Simpler version of documentation: The current documentation is AMAZING, but for someone that is looking for a tool like this might be too much at first. I think this could led people to not even trying it...

I suggest a simpler version of it as an entry point that covers:

• Installation
• basic usage
• reduced table of options (maybe the actual module help)

---

This are the main issues I found after trying it in a very simple module! Great job Kyle!, and thanks for sharing it 👏👏👏💪💪💪

[getify]

great feedback, thanks!

[getify]

Just curious, what error message did you get for (2)? Can you show the code and the error output? That would help identify how the error messaging should improve.

[horacioh]

$ mz --from="./src"
Invalid config: /Users/horacio/workspace/oss/remark-slate/.mzrc

• I tried it with this repo: https://github.com/hanford/remark-slate
• there is no .mzrc file in the repo

this is an ES6 repo, I would expect something more on the lines of source code is not a valid entry or something similar?

[getify]

Ahh, yes, that's a known issue. I was thinking maybe you got an obscure parsing error against an ESM file being parsed as a CJS file.

To be clear, the intent is, you should be able to run the tool without a .mzrc config file. It's just a simple mistake that it's expecting one and erroring without it.

But that's different from what may happen if it parses an ESM as a CJS.

Could you try adding an empty .mzrc file temporarily?

[getify]

OK, I just published v0.4.2 which fixes the bugs with a missing .mzrc or dependency-map.

Perhaps you could re-try it now with the update?

[horacioh]

hey @getify!

I was testing the module again with a cjs lib I have that I want to convert to esm and I couldn't find the config I need to make it work.

the library I want to convert is code generated from some Go code, but I need the code to be ESM because I'm using Snowpack for the JS App. apart from the code I have .d.ts files with it, dunno if that could help to generate the desired code?

I'm ok with sending the code if you want to test of give me some guidance! :)

thanks in advance and hope you and your family are safe and healthy!

[getify]

How do you want to share the code with me? Via gist? Or email it to me ([email protected])? Did you get any reported errors that would help identify what wasn't working?

[horacioh]

heres's the files!

https://github.com/horacioh/test-moduloze/tree/main

not getting an error, but not getting the expected result either XD hope the repo explains well the problem!, if not, please let me know to clarify anything!

[getify]

I discovered a bunch of bugs in moduloze v0.7.0, a lot of them related to incorrect/naive path handling. Took quite a bit of work to rewrite all that handling logic, but I landed those fixes in v0.8.0

Any chance you might be able to re-try your conversion with v0.8.0+ to see if it resolves any of the problems?

[horacioh]

sure thing!!

I did update to 0.8.0, and with the same config I'm getting this error:

→ yarn build
yarn run v1.22.5
$ ./build.js
/Users/horacio/workspace/playground/test-moduloze/node_modules/moduloze/src/esm.js:60
                        throw new Error(`Unknown module: ${ pathStr }`);
                        ^

Error: Unknown module: ./documents_pb.js
    at build (/Users/horacio/workspace/playground/test-moduloze/node_modules/moduloze/src/esm.js:60:10)
    at build (/Users/horacio/workspace/playground/test-moduloze/node_modules/moduloze/src/index.js:44:16)
    at Object.<anonymous> (/Users/horacio/workspace/playground/test-moduloze/build.js:17:15)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12)
    at internal/main/run_main_module.js:17:47
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Command failed: /Users/horacio/.yvm/versions/v1.22.5/bin/yarn.js build

Should I change something in the config? (build.js file)

[getify]

Actually, just looked closer at your code. I think the real problem is that the original file (the input to moduloze) is not in CJS format... that is, it doesn't have any module.exports or require(..) statements. That's what moduloze operates on. From what I can tell, moduloze isn't really changing anything about the file, other than parsing it and then re-generating from the AST.

[getify]

In your depmap, add:

"documents_pb.js": "someName"

[horacioh]

what about node_module deps? getting Unknown dependency: grpc-web and Unknown dependency: google-protobuf

sorry if this questions seem to be too obvious :(

[nfantone]

@getify Apologies for hijacking the thread, but today I tried running moduloze on a couple of repos I had and I keep getting:

npx -p moduloze mz --from=./src --build-esm
Invalid/missing dependency map (/path/to/project/package.json)

I've gone through the docs multiple times and I still don't quite get what a dependency map is, why it's needed or why is it trying to load it from package.json. I'm likely getting something backwards, but mapping or writing down every dependency of each project wouldn't really be feasible - or, rather, the effort to do so would probably be comparable to manually translate every module to ESM.

[getify]

@nfantone could you please start a new thread? I just tried this in a fresh/clean directory and it worked fine, so I wanna track down what's going on for you. The dependency-map is only required for the UMD format, so getting that error seems to indicate you're trying to build UMD even though that's not part of your command line arguments. That likely means a config file telling it to build UMD.

In the new thread, please let me know:

• what does npx -p moduloze mz --version report as the version?
• what does npx -p moduloze mz --help report for the various default options (like paths and build options)?
• if you have a .mzrc config in your project directory, what's its contents?
• if you have a package.json in your project directory, does it have a "mz-dependencies" key, and if so, what's its contents?

[nfantone]

@getify Here's the new issue: https://github.com/getify/moduloze/issues/17. Apologies again.