angular/packages/localize/localize.ts

16 lines
478 B
TypeScript
Raw Normal View History

/**
* @license
* Copyright Google LLC All Rights Reserved.
*
* Use of this source code is governed by an MIT-style license that can be
* found in the LICENSE file at https://angular.io/license
*/
feat(ivy): i18n - reorganize entry-points for better reuse (#32488) This is a refactoring that moves the source code around to provide a better platform for adding the compile-time inlining. 1. Move the global side-effect import from the primary entry-point to a secondary entry-point @angular/localize/init. This has two benefits: first it allows the top level entry-point to contain tree-shakable shareable code; second it gives the side-effect import more of an "action" oriented name, which indicates that importing it does something tangible 2. Move all the source code into the top src folder, and import the localize related functions into the localize/init/index.ts entry-point. This allows the different parts of the package to share code without a proliferation of secondary entry-points (i.e. localize/utils). 3. Avoid publicly exporting any utilities at this time - the only public API at this point are the global `$localize` function and the two runtime helpers `loadTranslations()` and `clearTranslations()`. This does not mean that we will not expose additional helpers for 3rd party tooling in the future, but it avoid us preemptively exposing something that we might want to change in the near future. Notes: It is not possible to have the `$localize` code in the same Bazel package as the rest of the code. If we did this, then the bundled `@angular/localize/init` entry-point code contains all of the helper code, even though most of it is not used. Equally it is not possible to have the `$localize` types (i.e. `LocalizeFn` and `TranslateFn`) defined in the `@angular/localize/init` entry-point because these types are needed for the runtime code, which is inside the primary entry-point. Importing them from `@angular/localize/init` would run the side-effect. The solution is to have a Bazel sub-package at `//packages/localize/src/localize` which contains these types and the `$localize` function implementation. The primary `//packages/localize` entry-point imports the types without any side-effect. The secondary `//packages/localize/init` entry-point imports the `$localize` function and attaches it to the global scope as a side-effect, without bringing with it all the other utility functions. BREAKING CHANGES: The entry-points have changed: * To attach the `$localize` function to the global scope import from `@angular/localize/init`. Previously it was `@angular/localize`. * To access the `loadTranslations()` and `clearTranslations()` functions, import from `@angular/localize`. Previously it was `@angular/localize/run_time`. PR Close #32488
2019-08-10 11:51:30 +00:00
// This file contains the public API of the `@angular/localize` entry-point
export {clearTranslations, loadTranslations} from './src/translate';
refactor(localize): init APF entry-point should not duplicate code (#45405) This commit addresses two issues: * The init entry-point currenly access code from another entry-point using relative imports, resulting in code to be duplicated. * The init types are now bundled as part of the ng_package APF rule. There is an API extractor bundling issue with global module augmentations. API extractor does not properly handle module augmentation. We need to disable dts bundling for this entry-point to ensure `$localize` remains globally accessible for users. This is an option in the `ng_package` rule. Note that this worked before because `localize/init` was a `ts_library` that did not have its types bundled. As part of this change, the `MessageId` and `TargetMessage` exports are also made public. The localize exported functions rely on these types but they were not exported. Related to types, an exception is added for three private exports from the primary entry-point so that they will show up in the API golden. These private exports are re-exposed publicly in the init entry-point but no golden would capture them due to the private symbol prefix. One might wonder why the symbols are not guarded in the init golden. The reason is that goldens never inline signatures from cross-entry-points/packages to avoid duplication. Lastly, the i18n integration test golden had to be updated because the polyfills bundle increased slightly. After thorough and time-consuming investigation, this mostly happens due to different mangle identifies being used (the input code changed --> so the mangling determinism) Size before this change: ``` SUCCESS: Commit undefined uncompressed runtime did NOT cross size threshold of 500 bytes or >1% (expected: 929, actual: 926). SUCCESS: Commit undefined uncompressed main did NOT cross size threshold of 500 bytes or >1% (expected: 124544, actual: 124660). SUCCESS: Commit undefined uncompressed polyfills did NOT cross size threshold of 500 bytes or >1% (expected: 34530, actual: 34641). ``` After: ``` SUCCESS: Commit undefined uncompressed runtime did NOT cross size threshold of 500 bytes or >1% (expected: 929, actual: 926). SUCCESS: Commit undefined uncompressed main did NOT cross size threshold of 500 bytes or >1% (expected: 124544, actual: 124650). FAIL: Commit undefined uncompressed polyfills exceeded expected size by 500 bytes or >1% (expected: 34530, actual: 35252). ``` Inspecting/comparing without mangling shows that the new changes would actually result in a bundle reduction (potentially visible with gzip/brotli): ``` ➜ Desktop stat -f%z master-nomangle.js 101357 ➜ Desktop stat -f%z with-changes-nomangle.js 101226 ``` PR Close #45405
2022-03-21 16:43:31 +00:00
export {MessageId, TargetMessage} from './src/utils';
// Exports that are not part of the public API
export * from './private';