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

Status for Ionic Standalone Bundle Size RFC? #29467

Closed
cwoebker opened this issue May 6, 2024 · 2 comments
Closed

Status for Ionic Standalone Bundle Size RFC? #29467

cwoebker opened this issue May 6, 2024 · 2 comments
Labels

Comments

@cwoebker
Copy link

cwoebker commented May 6, 2024

Hey all,

I quickly wanted to check what the process for the standalone bundle size RFC was, that was mentioned on the issue below. I looked through the forum as well and wasn't able to find something. Is there a potential timeline available for this?

Thanks a lot!

Also I believe migrating existing projects to this approach can be automated with a script (but I'm just guessing).

I haven't tried this, but at first glance this does seem possible.. We'd be migrating the import syntax which I believe is mostly consistent across frameworks (i.e. import { ... } from '@ionic/{angular/standalone, react, vue}'.

is it possible to actually support both ways of importing if you use a container index.ts file on the /standalone root path that exports everything? I'm not sure if my guess is correct but I think this will make it possible to not break currently imported components but still allow tree shaking if developers start refactoring their imports to be more specific.

Yeah that's a good thought. My understanding is the optimized code splitting solution could never export anything from @ionic/angular/standalone (i.e. everything would need to be something like @ionic/angular/standalone/[component]) otherwise we'd be back to the original problem noted in this thread.


Thanks for the feedback, everyone! As noted, our first step here is a public RFC to collect feedback from the community. We'll use that feedback to inform our decisions moving forward.

Originally posted by @liamdebeasi in #28574 (comment)

@sean-perkins
Copy link
Contributor

sean-perkins commented May 8, 2024

@cwoebker thanks for opening this issue. At this time I would encourage you to open a feature request or update this ticket to a feature request around the desired outcomes you are wanting from Ionic Framework.

We can then label the feature request to get feedback on the community's interest around these changes and we can use that to signal internally for prioritization.

--

My only initial concern with the recommendation in the linked thread is supporting both import patterns makes it extremely easy for a developer to import the "wrong" component that will be bundled in the main chunk. It offers a migration path, but we should work to remove this usage entirely if the limitation around bundlers cannot be resolved outside of separate entry points. I would recommend we deprecate the existing standalone component classes with any new entry points, to help guide developers before the next major release.

Personally I would love to get to:

import { IonButton } from '@ionic/angular/button';

but this requires either removing the IonicModule usage or migrating IonicModule to use the custom elements output instead of the lazy loaded components. This would be a net-neutral result on bundling, but could have runtime performance impacts for applications using only a small subset of Ionic components in their applications with IonicModule.

@sean-perkins sean-perkins added the needs: reply the issue needs a response from the user label May 8, 2024
@ionitron-bot ionitron-bot bot removed the triage label May 8, 2024
@thetaPC
Copy link
Contributor

thetaPC commented May 15, 2024

I wanted to touch base regarding this issue. As mentioned, this is better suited as a feature request rather than an ongoing issue. Since it hasn't been converted into a feature request yet, I'll be closing it for now. You're welcome to open a feature request whenever you're ready.

@thetaPC thetaPC closed this as not planned Won't fix, can't repro, duplicate, stale May 15, 2024
@ionitron-bot ionitron-bot bot added triage and removed needs: reply the issue needs a response from the user labels May 15, 2024
@thetaPC thetaPC removed their assignment May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants