Don't transpile to ES5

[laverdet]

This is meant as a discussion for a future major version of Apollo Client.

Right now the published package is using TypeScript's downleveling emit directives to compile to ES5. This irreversibly bloats the package with cruft that most users won't need. Additionally, it affects performance since native ES features are simulated using clunky workarounds. This is especially noticeable with async/await where any async functions compile into a state machine. This also affects nullish coalescing (??), optional chaining (?.), arrow functions, and a lot more.

My suggestion is to publish this package using the code as it was written and allow the user's bundler to perform transpilation and minification as configured.

This reduces the size of apollo-client.min.cjs from 120kb to 104kb which is pretty good for a one-line change.

Checklist:

• If this PR contains changes to the library itself (not necessary for e.g. docs updates), please include a changeset (see CONTRIBUTING.md)
• If this PR is a new feature, please reference an issue where a consensus about the design was reached (not necessary for small changes)
• Make sure all of the significant new logic is covered by tests

[netlify]

👷 Deploy request for apollo-client-docs pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	2f64899

[changeset-bot]

🦋 Changeset detected

Latest commit: 2f64899

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@apollo/client	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[phryneas]

Thank you for the pull request!

Unfortunately, we cannot introduce a bundling change such as this within a minor or patch update.
We have this on our Roadmap for Apollo Client 4.0, though, and will be doing changes to our bundling that will go far beyond the point of this PR.

So I'm going to close this PR for now, as it would need to stay open until we start the work on 4.0 - and then would immediately be superseded by a much bigger PR we would open ourselves.

[laverdet]

Thanks for taking a look.

Is the roadmap publicly accessible? This is semi-related to #9976 and #9890 which both remain open. It seems like there's a good bit of reasonably easy fixes outstanding on semver major which hasn't been touched in the 3 years since 3.x. I understand that there's marketing and developer outreach concerns but increasing the release cadence would be beneficial to users and also the Apollo team. For comparison, nodejs releases breaking changes 2 times per year, and TypeScript 4 times per year.

[jerelmiller]

@laverdet our public roadmap currently lives here. We will be planning v3.9 and beyond next week.

increasing the release cadence would be beneficial to users and also the Apollo team.

Definitely hear you on this point. We are in the midst of figuring out what our release cadence will be going forward so I would be willing to be we will naturally increase this cadence. I don't have a hard target to share yet (e.g. 2 majors per year), but know we are talking about this and are aware of this sentiment.