Skip to content

Conversation

@dnalborczyk
Copy link
Contributor

@dnalborczyk dnalborczyk commented Oct 8, 2021

I'm curious why this lazyRequire function exists. wouldn't it be sufficient enough to call require directly instead and achieve the same 'lazy' result?

if that's the case, I can spin up another PR or repurpose this one.

@nodejs-github-bot nodejs-github-bot added crypto Issues and PRs related to the crypto subsystem. needs-ci PRs that need a full CI run. labels Oct 8, 2021
@dnalborczyk dnalborczyk force-pushed the lazy-require-cache-map branch from 16f69b2 to a74731e Compare October 8, 2021 17:50
@dnalborczyk dnalborczyk force-pushed the lazy-require-cache-map branch from a74731e to 16daadc Compare October 8, 2021 17:53
@dnalborczyk dnalborczyk changed the title refactor: use map for lazy require cache crypto: use map for lazy require cache Oct 8, 2021
@jasnell
Copy link
Member

jasnell commented Oct 9, 2021

The lazyRequire() is named that way to make it clearer what is happening and that it's intentional. Switching to a map is good. Eventually, once we're sure all of the crypto stuff can safely be included in the startup snapshot (which is might be already, I'm not sure... @joyeecheung would know) then we can probably drop the lazy loading.

@joyeecheung
Copy link
Member

@jasnell I can tell from the user land snapshot prototype that (at least a basic subset of) crypto works in user land snapshot, which doesn't assume the snapshotted state to be stateless since it'll re-initialize the command line arguments etc. during snapshot dehydration. However I am not yet sure if it's safe to include crypto in the startup snapshot which needs to be stateless, since it's a lot of code to vet for now..

@dnalborczyk
Copy link
Contributor Author

dnalborczyk commented Oct 11, 2021

thank you @jasnell !

I think what I was trying to say is that to my understanding webcrypto is being lazily loaded because of having a getter exported:

get() { return lazyRequire('internal/crypto/webcrypto').crypto; }

webcrypto: {
  configurable: false,
  enumerable: true,
  get() { return lazyRequire('internal/crypto/webcrypto').crypto; }
},

lazyRequire uses a map for required references, but to my understanding that's what require() itself is already doing.

unless the internal require would be hoisted or the internal require works different than the "global" require, this would be pretty much the same:

webcrypto: {
  configurable: false,
  enumerable: true,
  get() { return require('internal/crypto/webcrypto').crypto; }
},

and for the crypto sub-modules loading, e.g. this:

return lazyRequire('internal/crypto/rsa')

case 'RSA-OAEP':
      return lazyRequire('internal/crypto/rsa')
        .rsaKeyGenerate(algorithm, extractable, keyUsages);

would be pretty much the same as:

case 'RSA-OAEP':
      return require('internal/crypto/rsa')
        .rsaKeyGenerate(algorithm, extractable, keyUsages);

both of the above examples using require instead are still requiring the modules lazily. in fact, lazyRequire seems to be just adding additional complexity without any benefits.

@aduh95
Copy link
Contributor

aduh95 commented May 11, 2024

This needs a rebase.

@aduh95 aduh95 added the stalled Issues and PRs that are stalled. label May 11, 2024
@github-actions
Copy link
Contributor

This issue/PR was marked as stalled, it will be automatically closed in 30 days. If it should remain open, please leave a comment explaining why it should remain open.

@github-actions
Copy link
Contributor

Closing this because it has stalled. Feel free to reopen if this issue/PR is still relevant, or to ping the collaborator who labelled it stalled if you have any questions.

@github-actions github-actions bot closed this Jun 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

crypto Issues and PRs related to the crypto subsystem. needs-ci PRs that need a full CI run. stalled Issues and PRs that are stalled.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants