-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Create unit tests and improve code resiliency for runtime.ts #509
Milestone
Comments
This sounds pretty interesting. Are there any limitations/parameters to how you want this done? |
@swist the only thing to mention is I do have my head around the problem and was likely going to try to tackle it over the next couple of days, though exactly how to expose and rationalise the API in runtime to be more testable was going to be sort of iterative. @ry wanted to put the unit tests in |
This was referenced Aug 14, 2018
Merged
hardfist
pushed a commit
to hardfist/deno
that referenced
this issue
Aug 7, 2024
…and#509) Calling `v8::ExternalReferences::new` does not take ownership of the Vec - it internally copies the values into a new Vec. As a result, the memory owned by the original Vec was never getting freed. Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are likely improvements to the logic, in particular, TypeScript invokes
host.resolveModuleNames()
several times to build a dependency graph, but currentlyruntime.ts
will attempt to fetch the code each time from the privileged side of deno.We also need unit tests to be able to better properly test the boundaries of the code and ensure it behaves as designed.
The text was updated successfully, but these errors were encountered: