deno_bindgen

I originally provided a PR https://github.com/denoland/deno_bindgen/pull/82 (merged) for this issue: https://github.com/denoland/deno_bindgen/issues/72 I have since discovered more about Rust compilation and procedural macros and realised my "fix" doesn't work as per this: https://github.com/rust-lang/docs.rs/issues/1823 The two issues with attempting to use : OUT_DIR is not defined when running any type of cargo build except when a exists. if OUT_DIR is defined (because a exists), the will output to as expected, but the does not have OUT_DIR defined and will default to looking for in the current working folder. I also see that my "fix" introduced another issue which was fixed here: https://github.com/denoland/deno_bindgen/pull/89 After learning more and understanding more... I humbly submit a PR which: rolls back the non-working fix: https://github.com/denoland/deno_bindgen/pull/82 rolls back the additional fix required for my non-working fix: https://github.com/denoland/deno_bindgen/pull/89 fixes a typo in the docs On my journey, I have also discovered that the issue of procedural macros having side-effects has been discussed elsewhere: https://github.com/rust-lang/cargo/issues/9084 It would seem this issue is a general issue with using procedural macros for outputting auxiliary data and out of my league in terms of resolving. I am not sure what the solution is, but for now I will have to put up with the fact that when my project makes use of deno_bindgen I can't refer to the generated Rust docs on docs.rs...

Hello, it would be nice if instead of eagerly loading the binary library synchronously would export a function called something like which would be a function that does and attaches all of the helper functions to an object that is returned. Therefore, people could instantiate multiple instances of their library in cases where there is different state that they want instead of having to write multiple awkward dynamic imports. Also, it would help when enabling testing and benchmarking in sub libraries that use deno bindgen to not always need to wait for the synchronous call to finish at the start of each run when it may not be needed.

The generated glue code should be able to be ran without requiring the internet the first time and there are also security vulnerabilities that can spawn from relying on third-party code. The external import for makes the calling of the FFI stuff does make it easier to cache in our code. However, I don't really think we should depend on external code sources, especially deno.land/x. If this project is under the same guise as the standard library's code manual (which I think it should), then it would violate the first STD-specific rule: ## Do not depend on external code. https://deno.land/std/ is intended to be baseline functionality that all Deno programs can rely on. We want to guarantee to users that this code does not include potentially unreviewed third party code. The fact of the matter is that it would need to be ensured with every version bump that all of the dependencies in the tree from /x/plug would need to be reviewed after every version for the dependency to remain safe. Every single person that uses this bindgen helper would be vulnerable if someone accidentally bumped the plug version without realizing there was a bad egg three levels down in the dependency tree that did some malicious stuff. Or, if x/plug or a sub dependency was using an untagged dependency in which case code that had been previously reviewed could have changed so no one would have ever known there was even a vulnerability. Now, I don't really have a good solution to this, though, as the caching implemented by and is really good. The only problem is that it's external code. Therefore, I'd just like to open this issue to open it for discussion and put out the idea of this being a possible issue along the line that we might need to fix.