"tree shaking" messages

[unional]

I think it is possible, but would be great if cli can support it.

The idea is this:

1. the app or library uses formatjs extract to extract all strings
2. the strings are translated by vendor and add back to the repo
3. during app bundle, tree shaking will create a bundle with only the components and messages actually used in that bundle
4. formatjs extract against the bundle to get the strings used
5. formatjs compile taking in both 1, 2, and 4, to produce localized messages that are actually used.

I think we can do step 1-4 already (a small question on 4, may need to do that during bundle instead of after bundle).

Step 5 is what's missing to today, AFAIK.

[longlho]

we've had a ton of discussions on this and from what I've seen at big tech, either they don't do it, or they split per feature (https://formatjs.io/docs/guides/distribute-libraries).
Most places don't do it, because it gives you next to no benefits. It's a static file that gets cached forever w/ versioning.

[unional]

Is translations loading your bottleneck?

Not exactly. I'm working on a MFE system and try to make sure we will have the correct workflow for dozen of teams. The distribute-libraries way might work with exports field if we manually separate the message files when calling formatjs (i.e. formatjs extract src/feature1/**.tsx) and then use the lang field (or exports field) to reference the files/folders. But that is a lot more complicated then able to "tree shake" the messages when each app bundles their code.

The other way is to separate the features into packages (e.g. in a monorepo). But that is a even harder sale.

[longlho]

Not to dunk on tree shaking but i have not seen it working properly at large scale. Large eng orgs form boundaries & ownership around teams and that's manual shaking. We've always been focusing on those use cases when it comes to scaling.

[longlho]

Generally teams build/own their own features and bootstrapping process (config/translations/data). Auto treeshaking creates non-determinstic bootlenecks that are hard to statically analyze at build time. It's also non-hermetic where it can break between versions and u can't test them properly.

[unional]

Not sure if I get the versioning part. Maybe one of the confusions is the main/app boundary.

For each MFE, there are two usages:

1. As MFE (main)
2. As library for other MFEs (app)

For 1, it only needs the messages from the components it uses, so tree shaking would help.

For 2, it needs to include messages from all the components it uses and exposes, as it acts like a library.
Tree shaking is optional in this case, but would help to avoid unnecessary version bumps (i.e. dependencies updated but the changes does not impact this MFE).

[longlho]

Yeah I'd avoid 2. Your MFE public surface is too big.
By versioning I mean you package translations into fr.hdiugrbs.json where the hash is the version. That gets cached forever.