Skip to content
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: support empty fallbacks #146

Merged
merged 1 commit into from
Aug 19, 2023

Conversation

markdalgleish
Copy link
Contributor

@markdalgleish markdalgleish commented Aug 18, 2023

The need for this came up in the context of Remix. Since route files in a Remix app contain code for both server and client and go through separate esbuild pipelines, we need to allow imports from all Node builtins in the client build, even those that don't have any polyfills. We then rely on tree shaking to remove code from unused imports in the client bundle.

Right now we handle unpolyfilled Node builtins by marking them as external in our esbuild config, but this approach is causing other issues (remix-run/remix#5521). It also means that any unpolyfilled Node builtin imports are left in the client bundle and throw an error at runtime. This change would allow us to remove our externals config and fix this issue.

Status and versioning classification:

  • Code changes have been tested and working fine, or there are no code changes
  • This PR changes the library's interface (methods or parameters added)

@@ -10,6 +10,7 @@ import type esbuild from 'esbuild';
const NAME = 'node-modules-polyfills';

export interface NodePolyfillsOptions {
fallback?: 'empty' | 'none';
Copy link
Contributor Author

@markdalgleish markdalgleish Aug 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went with this API so that it's more future proof, as opposed to emptyFallback: true or something similar. This way we can introduce different fallback behaviour in the future if needed without it being a breaking change, e.g. fallback: 'error' or fallback: (args) => { /* some custom logic... */ }. It also nicely mirrors the modules config option, making it clear that it's providing the same result.

Copy link
Owner

@imranbarbhuiya imranbarbhuiya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late response, I was out of the station. And thanks for the pr

@imranbarbhuiya imranbarbhuiya merged commit 5b26071 into imranbarbhuiya:main Aug 19, 2023
7 checks passed
@markdalgleish markdalgleish deleted the empty-fallbacks branch August 20, 2023 19:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants