Commit Graph

5 Commits

Author SHA1 Message Date
Joey Perrott 1d563a7acd build: set up all packages to publish via wombot proxy (#33747)
PR Close #33747
2019-11-13 11:34:33 -08:00
Pete Bacon Darwin 2cdb3a079d feat(ivy): i18n - implement compile-time inlining (#32881)
This commit implements a tool that will inline translations and generate
a translated copy of a set of application files from a set of translation
files.

PR Close #32881
2019-10-09 13:19:38 -07:00
cexbrayat d18289fa9c fix(ivy): missing schematics field in localize package (#33025)
The schematics added in #32791 is currently failing as the package.json does not reference it.

```
> ng add @angular/localize@9.0.0-next.9
+ @angular/localize@9.0.0-next.9
added 1 package from 1 contributor in 6.745s
Installed packages for tooling via npm.
The package that you are trying to add does not support schematics. You can try using a different version of the package or contact the package author to add ng-add support.
```

PR Close #33025
2019-10-07 10:21:29 -07:00
Pete Bacon Darwin 2bf5606bbe 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-09-12 15:35:34 -07:00
Pete Bacon Darwin b21397bde9 feat(ivy): implement `$localize()` global function (#31609)
PR Close #31609
2019-08-30 12:53:25 -07:00