Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error when using this inside of a npm workspaces monorepo #14

Open
adoublef opened this issue May 17, 2022 · 13 comments
Open

Error when using this inside of a npm workspaces monorepo #14

adoublef opened this issue May 17, 2022 · 13 comments

Comments

@adoublef
Copy link

adoublef commented May 17, 2022

Seems to fail when used in a npm workspace.

wasmPack error

details of the error as it is expecting the package the projects node_module directory which is not possible with the workspace

npm pacakge does exist

located in the root node_module directory of the workspace/monorepo

This is a Svelte not a SvelteKit project but unsure that would make a difference.

Module does exist here

@nshen
Copy link
Owner

nshen commented May 18, 2022

sorry, I have no idea what should I do with this.

@adoublef adoublef changed the title Error when using a npm workspaces Error when using this inside of a npm workspaces monorepo May 18, 2022
@adoublef
Copy link
Author

when using the second param, it looks into the node_module folder to locate the package. the first screenshot shows that attempt.

however if I have structured my whole directory as a npm workspace then there is two node_module folders; that projects one (which generally doesn't have much) & the global one (to share between different projects in that monorepo).

the issue is that the second param does not account for this & that is why it is assuming the directory does not exist.

however it does exisit (which is what the second screenshot on the leftside was supposed to show).

I am not sure how this could possibly be fixed.

I believe the examples that have been shown/tested have been solo projects not monorepos hence why this fault is showing up for me now.

@adoublef
Copy link
Author

in my example the expected path should be /workspace/examples/node_modules/@topheruk/hello-world/hello_world_bg.js

but I am seeing it say /workspace/examples/<path_to_sub_package>/node_modules/@topheruk/hello-world/hello_world_bg.js

@adoublef
Copy link
Author

adoublef commented May 18, 2022

The issue seems to lie with how you are creating the path inside the prepareBuild function.

I am trying to figure out where path_1.default is coming from as this is what I believe needs to change inorder for this to work

Inspecting this more and its the use of path.join path.resolve() on line 121, that I think is where you would want to check the top-level node_module directory in the current workspace somehow

@nshen
Copy link
Owner

nshen commented May 20, 2022

Hi, @topheruk could you try v0.1.12.

@adoublef
Copy link
Author

adoublef commented May 20, 2022

EDIT: It works, needed to add main field into my module's package.json as the module was not working (wasm-pack built my module without the main and will need to look into why that was the case)

Still an error Screenshot (34)

Do you have an example of a wasm module built with rust that I could try?

My wasm module, located [here[(https://www.npmjs.com/package/@topheruk/hello-world) & although it is listed on the npm registry & I can load it in a Svelte app (by copying the wasm file into public folder and calling it inside the init function, with this plugin its not working.

@greym0uth
Copy link
Contributor

greym0uth commented May 21, 2022

I have a PR (#16) going up for to fix a bundling issue I have (may not affect y'all) but here is an example of me using it in a monorepo with pnpm workspaces https://github.com/greym0uth/sorrakis

@nshen
Copy link
Owner

nshen commented May 23, 2022

hi @greym0uth, based on @topheruk 's report, seems require.resolve can only resolve main, not module ?

and sorry #16 changed too much, I don't have time to try this recently, I think I should revert it for now. I'll continue when I got time.

Is there a simple way to fix this? @topheruk , I never tried monorepo, but shouldn't the submodule have a link to global? I hope you can figure it out and do a pr. I 'm too busy with my work, and long time no touch rust :(

@adoublef
Copy link
Author

I will look into this resolving for modules for my needs its not super inconvenient to add the main key to the auto-generated package.json file.

would be worth just highlighting in the README for those using wasm-pack (unsure if Go/C/C#/etc. would have the same issue with their respective bundlers) that this step will need to be required in order for this too work.

wasm-pack does compile to commonJS that used the main key by default but that is mainly for nodejs applications not really the web apparently.

I can give @greym0uth the PR a go though I must preface this by saying I am new to issues & PRs on Github, so would need assistance on that front

@DoctorBracewell
Copy link

Hey I'm running into pretty much the same issue, @topheruk any updates? You mentioned adding the main key but that just throws me:
<package> doesn't appear to be written in CJS, but also doesn't appear to be a valid ES module?

Did you not run into that when you removed the module property and added main?

@adoublef
Copy link
Author

This week I'm going to have a deeper look at this issue as there is likely a few cases which need to be looked into. I didn't get that error but then there may have been a recent update to vite that introduced this so can't guarantee my fix still stands.

@DoctorBracewell are you using pnpm, npm or yarn? i am unsure if that should make a difference but worth sharing. also which version are you currently using?

This also my first attempt at dealing with a node project of this sort so not an expert at all.

@DoctorBracewell
Copy link

Currently using npm right now. I'll take a look at it was well if I have the chance, please keep us updated if you find anything :)

@DoctorBracewell
Copy link

I've made a comment on an issue in the wasm-pack repo and will probably look into a pull request for wasm-pack to add the main field to its output - not 100% sure if that PR might have any unintended side-effects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants