-
-
Notifications
You must be signed in to change notification settings - Fork 210
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
reduce node specific dependencies #1158
Closed
Closed
Changes from 6 commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
fb25ddc
#1158@trivial: Global 'performance' already provided by node >= v16.
mash-graz 5a5dfc7
#1158@patch: Inline isIP regex patterns to remove node:net dependency.
mash-graz 9f1de31
#1158@patch: Conditional import of 'webcrypt' from 'node:crypt'.
mash-graz c741829
#1158@trivial: Remove 'TextDecoder' imports (global in node >= v11).
mash-graz 4118e58
#1158@patch: Ignore absent process.plattform entry.
mash-graz 22cbd30
#1158@patch: Use global perfomance.now() instead of perf_hooks.
mash-graz 468e585
#1158@patch: Improved webcrypto import handling.
mash-graz File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I think we should avoid dynamic imports as it creates new problems.
Also in any case, we'd need to await this Promise, as right now the value of
globalThis.crypto
will bePromise {status: "resolved", result: ()}
(i.e. a resolved Promise wrapping the value of webcrypto).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.
Thanks for this feedback!
I'll look for a better replacement...
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.
It's now solved in a slightly modified manner:
A rather verbose variant to work around the prohibited top-level-await but still using dynamic import.
But the import should be only required for node < 19. In this particular case it will just have the same effect as in the original source code. But on most JS runtimes (more actual node releases / deno / browsers)
webcrypto
is already accessible asglobalThis.crypto
without any explicit import.We could avoid the dynamic import fallback by always importing
* from 'crypto'
and handle the conditional redirection later if needed, but it again wouldn't work with commonly used polyfill solutions out of the box.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.
Indeed for Node, it'll only be a problem on older environments, but even then, I'm not sure about this workaround. This will queue a microtask to polyfill
globalThis.cypto
, but as the surrounding code is synchronous, something could still try to access that property before it's ready.To avoid this weak point, I think ideally polyfilling crypto should be a responsibility of the user rather than the library, so that they can safely coordinate the polyfill flow (if needed at all) in their userland code.
resolve.alias
(or similar) to aliascrypto
to a local polyfill of webcrypto.package.json
, alias the Node SDK dependency to a local polyfill of webcrypto:web-crypto-polyfill
would be an npm package that pretty much just does this in its entrypoint JS file: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.
I really appreciate your critical review of the suggested code changes, but honestly I can't agree with your point of view in some significant aspects.
The
webcrypto
functions are in fact not needed by any internal processing inhappy-dom
. They are just reexported for WebAPI completeness as requested by #1050.Right now it's handling this job in a strict node-centric manner, which unfortunately isn't compatible with other JS runtimes.
For example in deno the
node:crypt
module isn't available at all and any import attempt throws an error. And in many common tools for automatic polyfilling node specific interfaces, like thevite-plugin-node-polyfills
used in my particular case,crypto
imports just get shimmed by empty objects. The documentation of these helpers often explicitly advice to avoid the incomplete dummy replacement in this particular case (for example: here).As a consequence of this lack of support under many circumstances, we are just shifting the issue from one level to the next one as long as we don't try to avoid this node specific imports wherever possible resp. replace them by alternative solutions and dynamic imports, which will be only activated in case of actually running on older node environments.
If we can't figure out a more satisfying and user-friendly solution, I would even suggest removing the
crypto
reexport again, which would at least eliminate the need of additional polyfills as long as this interface isn't actually required by an application.Nevertheless, I think, my suggested workaround could be seen as an acceptable compromise to minimize these compatibility issues in a more desirable manner.
But if you see any further improvements to process the async dynamic import in more proper fashion (e.g., in regard to the type definition in
IWindow
), I would be really happy to listen to your advice.