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

Support deno target #908

Closed
wants to merge 5 commits into from
Closed

Conversation

juzi5201314
Copy link

@OliverBrotchie
Copy link

Is there any update on this? It is mentioned in the docs already here.

@juzi5201314
Copy link
Author

As #879 (comment) said, wasm-bingen seems to have recently gained support for deno target, but the option is not forwarded to it by wasm-pack.

Copy link

@OliverBrotchie OliverBrotchie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes are very minor, I cannot foresee any conflicts or issues emerging.

@Sh4rK
Copy link

Sh4rK commented Oct 13, 2020

Hey everyone,

This seems like a relatively small change, but would help greatly in writing wasm modules for Deno, is there anything blocking this? Is there anything to do to get it merged?

Target::Deno => {}
_ => gitignore_contents.push_str("*")
}
fs::write(out_dir.join(".gitignore"), gitignore_contents)?;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of writing an empty file, it would be cleaner to not write it at all, I think.

But also, I'm nut sure this is necessary, why would targeting Deno be different in this regard? You might want to package up the resulting files into a separate repository (equivalent to putting it on npm for node), but at the same time want to keep the rust lib's source clean.

Having a wildcard .gitignore doesn't make sense in any other way, you obviously want to keep the results somewhere.

Copy link

@Mipsters Mipsters Feb 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this was the default behavior, they just removed that option for deno
the deleted line in 41 wrote * to .gitignore in every case, but @juzi5201314 probably concluded that it is not relevant for deno
this is still the state in the main branch (as of 2nd Feb, 2022)
and in the latest release atm
I agree about preferring not to create the .gitignore at all, but keeping the * for all other targets is just keeping the same behavior
changing this behavior is outside of the scope of this pr :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that we should leave create_pkg_dir as it is.
I could see one improvement to the status quo where we could read the current contents of an existing .gitignore before deleting the directory and then writing them back afterwards so modifications made by the user persist, but this should be a separate PR if it is a desired feature.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My comment is not very clear, reading it again now. I think my point was that this function should be left as-is, no need to special case it for Deno.

@olanod
Copy link

olanod commented Oct 22, 2020

This looks helpful, is it missing anything?

@Mipsters
Copy link

Mipsters commented Nov 21, 2020

I am using this branch, couple of problems I had

  1. wasm-pack build --help didn't list deno as a target option
  2. the .js generated in pkg doesn't manipulate the file path correctly for me
    (may be related to the fact that I use git bash as my main console)
    1. I use windows, yet the path string still comes with / and not \, so Deno.build.os === 'windows' ? '\\' : '/' give a wrong result
    2. new URL(import.meta.url).pathname gives a path with \ before C: for some reason?

except for this, it works perfectly!
took me some time to realize that I needed the .js suffix in the import in my deno code, but it did work!

edit: after thinking about it a bit, the problems in 2 are probably problems in wasm-bingen and not this pr
sorry if that's the case

@mindon
Copy link

mindon commented Sep 2, 2021

After another year ... it's not supported yet, the deno target

@egfx-notifications
Copy link
Contributor

I'd very much like to see this merged. Is anything holding us back? I'd be happy to provide the necessary adjustments if required.

@egfx-notifications
Copy link
Contributor

I am using this branch, couple of problems I had

1. `wasm-pack build --help` didn't list `deno` as a target option

2. the `.js` generated in pkg doesn't manipulate the file path correctly for me
   (may be related to the fact that I use git bash as my main console)
   
   1. I use windows, yet the path string still comes with `/` and not `\`, so `Deno.build.os === 'windows' ? '\\' : '/'` give a wrong result
   2. `new URL(import.meta.url).pathname` gives a path with `\` before `C:` for some reason?

except for this, it works perfectly! took me some time to realize that I needed the .js suffix in the import in my deno code, but it did work!

edit: after thinking about it a bit, the problems in 2 are probably problems in wasm-bingen and not this pr sorry if that's the case

@Mipsters Your point 2.2 seems to be fixed in the current wasm-bindgen release, the path is concatenated differently now.
2.1 I don't get right now, is Deno.build.os === 'windows' ? '\\' : '/' something you use in your code or something that wasm-bindgen created? Either way, I can't see this in output of current wasm-bindgen.
Your first point would definitely be an improvement to this PR.

@Mipsters
Copy link

Mipsters commented Feb 9, 2022

@egfx-notifications wow, I barely remember what I did then, but I think that the ternary condition was not mine
if I remember correctly, it was of some inner library, don't remember if it was part of the pr or something else
you can run a simple script to check if this is resolved, if Deno.build.os === 'windows' is true on windows then there is no issue
if you don't have a windows machine available, hit me up, but it'll take time for me to remind myself how to use any of this things...

@egfx-notifications
Copy link
Contributor

@egfx-notifications wow, I barely remember what I did then, but I think that the ternary condition was not mine if I remember correctly, it was of some inner library, don't remember if it was part of the pr or something else you can run a simple script to check if this is resolved, if Deno.build.os === 'windows' is true on windows then there is no issue if you don't have a windows machine available, hit me up, but it'll take time for me to remind myself how to use any of this things...

Then this seems to be fixed now. Tried cmd, Powershell and Git Bash on Windows, all give the correct result.

Copy link
Contributor

@egfx-notifications egfx-notifications left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As stated in the comments, please remove the modifications to create_pkg_dir.

Please also add deno to the list here so it will be listed as available option in the --help output.

Target::Deno => {}
_ => gitignore_contents.push_str("*")
}
fs::write(out_dir.join(".gitignore"), gitignore_contents)?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that we should leave create_pkg_dir as it is.
I could see one improvement to the status quo where we could read the current contents of an existing .gitignore before deleting the directory and then writing them back afterwards so modifications made by the user persist, but this should be a separate PR if it is a desired feature.

@drager
Copy link
Member

drager commented Jul 5, 2023

Fixed in #1117.

@drager drager closed this Jul 5, 2023
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

Successfully merging this pull request may close these issues.

8 participants