You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
doc,crypto: import from 'node:crypto' instead of import('node:crypto') #45884
in the esm example of the first paragraph there is this import: const { createHmac } = await import('node:crypto');
It seems weird, shouldn't be import { createHmac } from 'node:crypto': ?
If so I can open a PR to fix it
Node.js can still be built without crypto support. If you want to right your code in a way that takes this into account, you can't use static imports and need to try/catch a dynamic import. If you only want to support Node.js built with crypto, you can use static imports.
I wonder if now ESM import throws and therefore we can remove this special use case.
Importing node:crypto from ESM on a build without support for it has always thrown AFAIK, not sure what you mean @ShogunPanda.
@aduh95 Nothing, I misunderstood what was the reason in the issue above.
Now that ESM has settled for a while, do you think we should change to be consistent with the rest of the docs?
The use of dynamic imports in crypto.md had nothing to do with ESM having settled or not, the reason for doing it (some Node.js builds do not ship with node:crypto) is still valid – or rather, is as valid as it was at the time. I personally don't have an opinion one way or another, and certainly don't oppose re-evaluating our position on this, I'm happy to defer to folks who have more thoughts on the topic.
My opinion here is that we should write example for the majority of users, and eventually a specific example right after for people that don't have crypto enable.
Reopening at it seems to have created a discussion.
Normally the user would not use a custom build without crypto, so in my opinion the documentation should reflect that.
We should obviously explain that in the case crypto module is not included in the build it should be handled and provide and example.
If you agree I can create a PR to change this.
The problem then is that it ain't so type/ide friendly without having to add extra annotation. + it is now mutable instead of being a const.
ppl overlook the use of catch now that we got async/await
i would write it more like:
constnodeCrypto=awaitimport('node:crypto').catch(()=>{})consthash=nodeCrypto?.createHmac('sha256',secret).update('I love cupcakes').digest('hex')if(hash){ ... }if(nodeCrypto){ ... }
or actually use good old .then(...) (not everything must be written with async/await) sometimes i try to break out of promise chain hell when i can do so.
Activity
panva commentedon Dec 16, 2022
This is intentional. Because Node.js can be built without crypto support and only the function-like
import()can be caught.https://nodejs.org/api/crypto.html#determining-if-crypto-support-is-unavailable
marco-ippolito commentedon Dec 16, 2022
Is it the standard to be built without crypto support? Shouldnt the example be with the most common use case?
panva commentedon Dec 16, 2022
It is what got consensus in #37594
marco-ippolito commentedon Dec 16, 2022
All right I'm gonna close this as it seems not to be a bug
ShogunPanda commentedon Dec 19, 2022
I wonder if now ESM import throws and therefore we can remove this special use case.
@nodejs/tsc Tagging you because probably you have more insight on it.
aduh95 commentedon Dec 19, 2022
Node.js can still be built without crypto support. If you want to right your code in a way that takes this into account, you can't use static imports and need to
try/catcha dynamic import. If you only want to support Node.js built with crypto, you can use static imports.Importing
node:cryptofrom ESM on a build without support for it has always thrown AFAIK, not sure what you mean @ShogunPanda.ShogunPanda commentedon Dec 19, 2022
@aduh95 Nothing, I misunderstood what was the reason in the issue above.
Now that ESM has settled for a while, do you think we should change to be consistent with the rest of the docs?
aduh95 commentedon Dec 19, 2022
The use of dynamic imports in
crypto.mdhad nothing to do with ESM having settled or not, the reason for doing it (some Node.js builds do not ship withnode:crypto) is still valid – or rather, is as valid as it was at the time. I personally don't have an opinion one way or another, and certainly don't oppose re-evaluating our position on this, I'm happy to defer to folks who have more thoughts on the topic.ShogunPanda commentedon Dec 19, 2022
My opinion here is that we should write example for the majority of users, and eventually a specific example right after for people that don't have
cryptoenable.@panva Any thought on this?
panva commentedon Dec 19, 2022
Sure, that was my position in the original PR too but at that point this is what we agreed to land.
#37594 (review)
GeoffreyBooth commentedon Dec 20, 2022
It seems weird that the example uses
await import()but it isn’t within atryblock:I would think it should look something like this:
panva commentedon Dec 20, 2022
Neither are the CJS examples but the point is that the syntax used is try-catcheable.
marco-ippolito commentedon Dec 20, 2022
Reopening at it seems to have created a discussion.
Normally the user would not use a custom build without crypto, so in my opinion the documentation should reflect that.
We should obviously explain that in the case crypto module is not included in the build it should be handled and provide and example.
If you agree I can create a PR to change this.
panva commentedon Dec 20, 2022
cc @tniessen @jasnell
[-]doc: createHmac import [/-][+]doc,crypto: import from 'node:crypto' instead of import('node:crypto')[/+]jimmywarting commentedon Jan 2, 2023
Not so particular fan of using this pattern:
The problem then is that it ain't so type/ide friendly without having to add extra annotation. + it is now mutable instead of being a
const.ppl overlook the use of
catchnow that we got async/awaiti would write it more like:
or actually use good old
.then(...)(not everything must be written with async/await) sometimes i try to break out of promise chain hell when i can do so.