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.

Sign up for GitHub

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

Jump to bottom

Native federation: support Angular i18n (partially) #413

Open
refactorTractor opened this issue Dec 18, 2023 · 9 comments · May be fixed by #627
Open

Native federation: support Angular i18n (partially) #413

refactorTractor opened this issue Dec 18, 2023 · 9 comments · May be fixed by #627

Comments

@refactorTractor
Copy link

Hi!

Supporting angular i18n is a pretty important feature for me.

I think native federation can handle a partial scenario pretty easily. I assume that most shared modules are locale-agnostic - only the angular app itself requires inlining translations. So a logical first step could be to support a localized main-bundle with locale-independent shares.

It seems like this concept fits the architecture of native federation, because the main bundle's build is up to angular-devkit/esbuild-browser, and shared modules are bundled using esbuild natively.

(I imagine that later down the line shared packages would have to be checked whether they're produced by ng-packagr, and then you could integrate their localizations.)

Anyway, for this first step I created #411 , please consider it.
@refactorTractor refactorTractor mentioned this issue Dec 19, 2023
Closed
@refactorTractor
Copy link
Author

refactorTractor commented Jan 31, 2024 •
edited
Loading

Hi!

I've realized that the solution that is in the PR will not work, but I have since dug into the angular application builder too. What I found, was that most of the esbuild options match, and that your builder and that one has some differences in build steps.

Angular builder native federation build adapter
has a bunch of extra esbuild options set: asset names, conditions, resolve extensions, metadata, legal comments, pure forwardRef, out extension, splitting, chunk names, tsconfig, preserve symlinks, loader, footer, public path, main fields. I've marked with bold the options I think could interfere if we used the application builder inside the nf adapter. I saw however that esbuild plugins can edit build options, so splitting and chunk names should be no problem to remove. In case of preserving symlinks I don't know whether that could have detrimental consequences. has 1 extra esbuild plugin for shared mappings. This can programmatically be given to the angular application builder, so I guess that could work.
does a separate polyfill bundle. I think we don't have to consider that. I'm not sure it's a good idea for remotes to potentially overwrite polyfills. A good first step could be to simply accept the polyfills of the host. Later the polyfill bundle could dynamically import federated polyfills. Maybe.
Angular builder does localization inline-ing. That's what I'm here for. It also takes care of the SSR, app shell parts. I don't know what effect that has on the browser bundle, so I'm opting out of supporting them in my work / assuming there are no such features enabled. Another feature used is legal comments, but those are just comments. It does one additional step, and that is it does linking using the angular compiler-cli linker. I don't know what that is for, and whether it is still relevant if the application builder does the building.

With all that in mind, I'm considering two different ways to go forward.

  1. using the angular application builder inside the adapter instead of esbuild directly. What I don't know is whether that is good for both shared and exposed modules. If shared modules are better done with a native esbuild, then the adapter has strategize based on the kind of bundle it has to make.
  2. just making a completely different builder that sets up the angular application builder based on the federation config, but without actually using the buildForFederation build tool. In this case I would aggregate all the different entries, shared and exposed alike, and hope that no linking is needed and that they all play nicely even after the angular compiler does it's passes with legal comments, localization inlining, etc...

@manfredsteyer Please give your feedback on the approaches, any issues I didn't notice, or things I'm making an issue about that aren't actually problems.

Oh yeah, and once I have the build, serving would be nice, but I haven't yet thought that through.

@refactorTractor refactorTractor mentioned this issue Feb 1, 2024
Closed
@refactorTractor
Copy link
Author

@manfredsteyer to help process everything I wrote in my previous comment: see this latest (draft) PR #456 . (It's still a work in progress, but the changes to the adapter are mostly done.) It showcases what option 1 would look like.

@refactorTractor
Copy link
Author

@manfredsteyer With my current progress I was able to make it work on my example project. I ask you to please review my code and give me feedback.

@refactorTractor
Copy link
Author

Hi,
so here's where I'm at:

  • I've created a library internal for my company based off of this version.
  • For some reason that's beyond me, I received NG0203 errors if I built with <17.1.0, so this PR includes a version bump.
  • There seems to be some sensitivity to how and where you set baseHref. It needs to be set in the i18n as well as the build target's options, with a leading and trailing /.

Other than these hiccups, it seems to work like a charm. I set up language specific configurations that I can run in parallel, in order to run multiple dev servers.

I still have an open question: I'm not sure mappings should also go through the angular builder, maybe those should have also been sent through esbuild.

@manfredsteyer Your review and feedback would be very welcome!

@RaphaelJenni
Copy link

@refactorTractor We are currently looking into the same issue. Thanks for all the legwork!

@manfredsteyer It would be nice to get a response from you, also regarding #404, if this will ever be supported (or why not).

@ChrTopf
Copy link

ChrTopf commented May 4, 2024 •
edited
Loading

Hi everyone,
i would be interested in i18n support for native federation as well.

P.s. @refactorTractor you should probably remove the siemens URL from your PR#456 ;)

@WizzardMaker
Copy link

Would also love to see support for such a crucial feature

@nbonneau
Copy link

+1

@refactorTractor refactorTractor linked a pull request Aug 23, 2024 that will close this issue
Open
@refactorTractor
Copy link
Author

refactorTractor commented Aug 23, 2024 •
edited
Loading

@RaphaelJenni @ChrTopf @WizzardMaker @nbonneau I've released my changes in a package for 17.3.2: @fork-fork/native-federation My project at siemens uses it with success so far. Please try it out. Any feedback is welcome.

One hint though: I only changed the native-federation package, nothing else. This comes with one drawback here: I couldn't add this package to the default skip list, so you'll have to add this package to it manually in your federation.config

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
5 participants
@refactorTractor @WizzardMaker @nbonneau @RaphaelJenni @ChrTopf