-
Notifications
You must be signed in to change notification settings - Fork 70
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
fix(js): defer library loading for nodejs #173
Conversation
Signed-off-by: Ariel Gentile <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two main comments, otherwise its a very minimal change that would be a good addition.
// eslint-disable-next-line @typescript-eslint/ban-ts-comment | ||
// @ts-ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both of these can be removed now.
@@ -3,13 +3,13 @@ import type { IndyVdrErrorObject } from '@hyperledger/indy-vdr-shared' | |||
import { IndyVdrError } from '@hyperledger/indy-vdr-shared' | |||
|
|||
import { allocateString } from './ffi' | |||
import { nativeIndyVdr } from './library' | |||
import { getNativeIndyVdr } from './library' | |||
|
|||
export const handleError = (code: number) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing this now, I would say it makes more sense to have handleError
as a private method on the NodeJSIndyVdr
class. Could you include that in the PR?
Signed-off-by: Ariel Gentile <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Prevent native library from being loaded right when
@hyperledger/indy-vdr-nodejs
is imported by deferring its loading to when it's actually used.This is a problem we found during AFJ test suites, which import the library in general purpose test helpers and make the native library to be loaded more times than needed, allocating more memory and making the suite to crash.