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

updating of experimental options #27031

Closed
1 of 7 tasks
danielroe opened this issue May 1, 2024 · 3 comments · Fixed by #27132
Closed
1 of 7 tasks

updating of experimental options #27031

danielroe opened this issue May 1, 2024 · 3 comments · Fixed by #27132
Assignees

Comments

@danielroe
Copy link
Member

danielroe commented May 1, 2024

With the v4 release, we have an opportunity to simplify our current list of 'experimental' features:

  • remove treeshakeClientOnly experimental option (enabled by default since v3.0.0)
  • remove configSchema option (enabled by default since v3.3.0)
  • remove polyfillVueUseHead (disabled since v3.4.0) - implementable in user-land with plugin
  • remove respectNoSSRHeader (disabled since v3.4.0) - implementable in user-land with server middleware

I would also like to remove renderJsonPayloads option (enabled by default since v3.5.0) but there seem to be a number of repositories using it and I think we need to investigate why and help them migrate to JSON payloads first.

In addition, I think we can consider enabling the following options by default sooner than 4.x:

  • headNext (cc: @harlan-zw - what do you think?)
  • scanPageMeta
  • sharedPrerenderData

Thoughts welcome 🙏

@danielroe danielroe self-assigned this May 1, 2024
@harlan-zw
Copy link
Contributor

polyfillVueUseHead can definitely be removed, @vueuse/head has been sunset for almost a year

headNext may also be worth removing if we're considering moving things under the module key meta, the Capo implementation can be enabled by default in the next Unhead release

@manniL
Copy link
Member

manniL commented May 2, 2024

Happy with all the considerations 👍🏻
Especially enabling more of the options (as they can be easily disabled if things go "wrong")

For each removed feature/flag which could be a user-land implementation it'd be great to give an example in the release notes / migration guide / blog post, so people can easily "migrate" if they need said behavior.

@Dmytro-Tihunov
Copy link
Sponsor

Dmytro-Tihunov commented May 2, 2024

Thanks, looking forward to new updates, probably headNext can be removed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants