Add an option to parse FTL during build

[Demivan]

Description

Add an option to do FTL parsing during build instead of during runtime on component initialization.

Option parseFtl?: boolean for both SFC and External plugins.

Linked Issues

Closes #101

Additional context

[pkg-pr-new]

Open in Stackblitz

pnpm add https://pkg.pr.new/fluent-vue/unplugin-fluent-vue@107

commit: 33d9616

[rangermeier]

Thanks @Demivan for preparing this PR. I just tried the parseFtl option on the project I'm currently working on. It's a small project, it uses only two locales and there are currently ~150 strings in each FTL file.

My observations:

• File size of parsed FTL files is larger, in my case it went from 13.58kb to 24.46kb uncompressed. With GZIP compression it's 4.97kb vs. 5.51kb.
• With parsed FTL file resource.js from fluent-bundle is not packaged anymore, which saves 17.56kb (GZIP 4.6kb)
• Performance: There is a measurable but very small performance improvement when loading parsed FTL files, see the table below.

Method	raw FTL	parsed FTL	note
static import	0.21-0.26ms	0.09-0.15ms	import strings from './locales/en.ftl'
dynamic import	6-18 ms	5-15ms	const strings = await import('./locales/en.ftl')

So, all in all I think it's hard to draw an decisive conclusion which approach should be preferred. For projects with little strings there is in total a small advantage in file size. With more strings, the savings from omitting the FluentResource class will be shadowed by the larger FTL files.

During build I get the following warning, if parseFtl: true is set:

src/locales/en.ftl (1:0): A comment

"/*#__PURE__*/"

in "src/locales/en.ftl" contains an annotation that Rollup cannot interpret due to the position of the comment. The comment will be removed to avoid issues.

[Demivan]

@rangermeier Thanks for such an extensive testing.

I get similar results on my project too. We have a lot more translations, so size diff was +14Kb (Gzip) instead of a reduction, and performance improvement was ~3ms for an average page.

So for small projects, this is clearly a nice addition. You get a smaller bundle size and slightly better performance. For big projects, time to download a bigger bundle would, most likely, negate the runtime performance gain. One benefit I see for big projects is that after a browser caches the bundle, you just get a performance gain with no downside.

I think, I will polish this PR, fix the warning that you got, and merge it. But I'm on the fence whether this should be enabled or disabled by default.