-
Notifications
You must be signed in to change notification settings - Fork 22
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
feat(cloudflare): introduce hybrid polyfills for the cloudflare preset #224
Conversation
@pi0 this one is a bit controversial as it introduces a new preset. We could modify the existing cloudflare preset, but that would most likely be a breaking change for existing nitro apps, so we need to be careful here. I'm really hoping that this extra preset is just a temporary thing we need to do to avoid a breaking change, but once nitro/nuxt is updated, we should drop the old preset and keep just this new one. I called the preset What do you think? |
0046dba
to
3e58051
Compare
Thanks for the PR! Currently unenv's |
@IgorMinar Just to double check is |
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 would suggest to adopt a convention like $cloudflare
or $workerd
for file naming to clearly indicate they are platform-specific overrides, really nice idea btw we could extend this convention 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'm good with $cloudflare
. I'll update the PR.
it will be. we'll need to coordinate the GA with [email protected] |
Excellent! I wasn't sure about the existing usage of the preset. I also agree that v2 will make getting this out easier. In that case, I will go ahead and merge the cloudflare and cloudflareV2 presents into one. |
3e58051
to
d338793
Compare
d338793
to
800ebd8
Compare
@pi0 I addressed all your review feedback. PTAL |
scryptSync, | ||
sign, | ||
verify, | ||
} = unenvCrypto; |
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.
Would it make sense that we use export { ... } from './index'
to improve the tree-shaking possibility (in case of ESM imports)?
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 believe that this will tree-shake just fine because everything is statically analyzable, but I'll verify.
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 bundler would be confused because we first import as namespace then use (runtime) restructure. At least it cannot be a safe treeshake for it because namespace import can have side-effects as well as destructure
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.
there is indeed a problem with tree-shaking. take a look at this...
Destructured import usage:
Namespaced import usage:
So the last pattern is the way to go even though it's the most verbose. Oh well...
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.
This seems like the kind of optimization that rollup could handle automatically. Maybe one day. I got too spoiled by the capabilities of Closure Compiler at Google.
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.
Other than two suggestions seems nice upgrade!
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.
Changes LGTM.
Quick sanity check: it seems like there's quite a few more modules that need similar treatment: diagnostics_check
, async_hooks
, path
, process
, stream
...etc
Are we going to tackle those in a followup PR?
@jculvey those will be in separate PRs. I don't want to expand the scope of this one any more. I just wanted to implement a few to prove that the technique works for many modules. |
800ebd8
to
3a05249
Compare
Feel free to merge whenever ready @IgorMinar i'm fine with treeshaking being deferred. |
In #242 i'm moving node internals to |
This preset now provides hybrid polyfills which temporarily require special workerd compat flags. This is most likely a breaking change, and will require us to release it as [email protected]
dda197a
to
f239524
Compare
Feel free to merge whenever ready @IgorMinar i'm fine with treeshaking being deferred. @pi0 I just finished the refactoring and pushed. It turned out to be a slightly bigger refactor but nothing too surprising: f239524 If CI is also green, I'll merge. |
This preset provides hybrid polyfills (#181) but requires special workerd flags.
Due to potential for breaking changes and extra requirements, we created a new preset rather than updating the existing one.
In the next major version of unenv, we should remove the cloudflare preset and rename cloudflareV2 to cloudflare.
🔗 Linked issue
#181
❓ Type of change
📚 Description
📝 Checklist