Repository navigation
Conversation
7742649 to
5019827
Compare
AndrewKushnir
left a comment
There was a problem hiding this comment.
@ocombe looks good! Just left a couple minor comments. Thank you.
|
Blocked by https://angular-team.atlassian.net/browse/FW-1076 (bazel issue) |
e2c6635 to
8ef7ee5
Compare
Alex got #21883 merged which should resolve FW-1076. You should be unblocked on master. |
8ef7ee5 to
a578389
Compare
|
@gregmagolan just rebased on master and it doesn't change anything for me. It still doesn't take the tsconfig into consideration. Am I supposed to change something else to the bazel build file to make this work? |
f4f2e48 to
aebd03a
Compare
7618e6a to
3afbb98
Compare
IgorMinar
left a comment
There was a problem hiding this comment.
can you please address the comments I posted and split this PR into two - one for cli update to beta.11 and one for the remaining changes. that way we can isolate the payload size regression and attribute it to this change or an issue in cli. thanks
There was a problem hiding this comment.
can you please not change this. if you need a newer version, then you should update the root package.json and not this one.
There was a problem hiding this comment.
we talked about this at the framework meeting yesterday and it was decided to only change this in the ivy integration apps for now
There was a problem hiding this comment.
can you please share why?
my concern is that we are making our integration testing infrastructure more fragile if we make this change and we are increasing technical debt. I'd prefer not to make a change like that unless we really really have to (and then there should be a follow up work to remove this temporary hack which should be tracked and scheduled so that we don't forget).
There was a problem hiding this comment.
why will this happen? if this really is a TODO then we should likely have an item in jira for this. If this is just a note then make it a note and not a TODO
There was a problem hiding this comment.
Because ɵi18nConfigureLocalize is just temporary (as explained in its api docs) until we can work on the service. We needed something for our tests to make i18n work without closure so that people can test ivy even if they use i18n.
There is a already jira ticket for the runtime service (not specifically this todo, but it's part of it).
There was a problem hiding this comment.
let me try to explain my question better: if I'm reading this todo in the codebase a month from now, what should I do, how should I interpret it, or how can I learn more about what this comment stands for?
In its current form, all I can do is ask you personally what this is about and where I can learn more, and that doesn't scale.
There was a problem hiding this comment.
I've updated the todo, let me know if it is still unclear.
|
@IgorMinar the size regression was present before the cli change. I tried to update the cli version to see if my change to tree shake |
32d8695 to
29445e6
Compare
|
I removed the cli changes, and rebased onto master and it fixed the size regression issue. @IgorMinar can you approve the PR now? :) |
IgorMinar
left a comment
There was a problem hiding this comment.
lgtm except for that one todo
129e4c7 to
092e71b
Compare
So far using runtime i18n with ivy meant that you needed to use Closure and `goog.getMsg` (or a polyfill). This PR changes the compiler to output both closure & non-closure code, while the unused option will be tree-shaken by minifiers. This means that if you use the Angular CLI with ivy and load a translations file, you can use i18n and the application will not throw at runtime. For now it will not translate your application, but at least you can try ivy without having to remove all of your i18n code and configuration.
|
previews presubmit failed, so here is a new one after the last set of changes: http://test/OCL:243069482:BASE:243069609:1554994952547:fae7a7a0 |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
So far using runtime i18n with ivy meant that you needed to use Closure and
goog.getMsg(or a polyfill). This PR changes the compiler to only output closure code when the compiler optioni18nUseClosureis set to true. This option is set to false by the compiler-cli when the optioni18nInFileis used, which is what happens when you load a translations file.This means that if you use the Angular CLI with ivy and load a translations file, you can use i18n and the application will not throw at runtime.
For now it will not translate your application, but at least you can try ivy without having to remove all of your i18n code and configuration.