Skip to content

[v9] Drop polyfills from build output #8795

Closed
@mydea

Description

@mydea

Currently, we include a few polyfills in our build:

_asyncNullishCoalesce
_asyncOptionalChain
_asyncOptionalChainDelete
_createNamedExportFrom
_createStarExport
_interopDefault
_interopNamespace
_interopNamespaceDefaultOnly
_interopRequireDefault
_interopRequireWildcard
_nullishCoalesce
_optionalChain
_optionalChainDelete

These are a bit tricky, increase complexity and build size.

These can be split into two categories:

  1. nullish coalesce & optional chaining polyfills
  2. Bundler-related polyfills

The first category is actually disallowed by eslint rules, as the polyfills increase bundle size considerably when used. We do not use any nullish coalesce/optional chaining in all core/browser SDKs, only in node & nextjs.

I propose to remove these polyfills in v8, if we decide to bump the min. Node version to 14+. Node 14 supports both nullish coalescing as well as optional chaining.

I propose to leave the eslint rules for core/browser SDKs in place, but simply rely on them to ensure we don't use them outside of node context. We also have tests covering that the ES5 CDN bundles are valid ES5, which should cover any regressions there. This allows us to get rid of these polyfills:

_asyncNullishCoalesce
_asyncOptionalChain
_asyncOptionalChainDelete
_nullishCoalesce
_optionalChain
_optionalChainDelete

The other category of polyfills:

_createNamedExportFrom
_createStarExport
_interopDefault
_interopNamespace
_interopNamespaceDefaultOnly
_interopRequireDefault
_interopRequireWildcard

I propose we investigate if we can solve this with rollup instead.

Benefits of dropping the polyfills

  • Reduced complexity in our codebase & build
  • No need to have non-canonical exports (currently polyfills are imported directly from e.g. @sentry/utils/esm/buildPolyfills/index.js which is not ideal)
  • Reduced bundle size/increased performance for platforms that do support these (e.g. newer node) - can use native instead of polyfilled code
  • Browser/core packages already don't use these features, so no migration work necessary there

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions