angular: @angular/localize should not depend on @angular/compiler
Which @angular/* package(s) are the source of the bug?
localize
Is this a regression?
No
Description
Currently @angular/localize depends on @angular/compiler https://github.com/angular/angular/blob/main/packages/localize/src/utils/src/messages.ts#L8
@angular/complier is a huge package that does not execute outside of node.js. For this reason, it is not possible to use it with edge functions.
Please provide a link to a minimal reproduction of the bug
https://github.com/angular/angular/blob/main/packages/localize/src/utils/src/messages.ts#L8
Please provide the exception or error you saw
`@angular/compiler` can not be loaded at edge functions such as Cloudflare, Netlify, etc...
Please provide the environment you discovered this bug in (run ng version)
No response
Anything else?
I think the computeMsgId should be in @angular/localize (and @angular/compiler can import it from there)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 6
- Comments: 27 (25 by maintainers)
Commits related to this issue
- refactor(localize): remove the dependency on `angular/compiler` The original plan for `$localize` was that it would be independent of Angular. Currently there is a dependency on `@angular/compiler` d... — committed to petebacondarwin/angular by petebacondarwin 2 years ago
- refactor(localize): bundle message digest algorithm directly in npm package The main entry point for the `@angular/localize` package no longer imports the `@angular/compiler` package and now has no e... — committed to clydin/angular by clydin a year ago
- refactor(localize): bundle message digest algorithm directly in npm package The main entry point for the `@angular/localize` package no longer imports the `@angular/compiler` package and now has no e... — committed to clydin/angular by clydin a year ago
- refactor(localize): bundle message digest algorithm directly in npm package (#48799) The main entry point for the `@angular/localize` package no longer imports the `@angular/compiler` package and now... — committed to angular/angular by clydin a year ago
- refactor(localize): bundle message digest algorithm directly in npm package (#48799) The main entry point for the `@angular/localize` package no longer imports the `@angular/compiler` package and now... — committed to trekladyone/angular by clydin a year ago
After talking over the issue internally, we would like to avoid adding to the public API surface if possible. Code duplication in the final output bundles of the packages shouldn’t be a problem especially since the amount of code is fairly minimum (and should be even smaller soon with some upcoming refactoring). With that in mind, a separate build target for the digest code that is then used as a build dep for each package should allow for a single repo source code location while meeting the requirement of independent package output bundles.
I’ve replied on Pete’s PR (https://github.com/angular/angular/pull/48178#issuecomment-1324423545), posting here for visibility as well: it looks like code duplication is the best option for now and we’ll followup with extra cleanup to the i18n subsystem afterwards.
Thank you!
Quick update: @clydin created a PR (https://github.com/angular/angular/pull/48799) which should allow the
@angular/localizepackage no longer import the@angular/compilerpackage and the message digest algorithm implementation from the@angular/compilerpackage is bundled directly into the final npm package for@angular/localize. The PR was marked as ready for merge, so it’s likely that the change will make it into one of the upcoming patch releases of Angular.@mhevery sorry for the delay! We plan to take a look at the option described in https://github.com/angular/angular/issues/48163#issuecomment-1335805181 asap and update this thread with additional info.
Hate to be that person on the internet, but can I poke this issue to see if we could get some progress on this?
OK, so it seems that moving
computeMsgId()to a side-effect free sub-package (e.g.@angular/compiler/digest) is the simplest solution. right?I don’t see any issue either way but:
Voila! I am not sure if this counts as breaking. I thought there might be some G3 changes
Although I see that it is still needed for legacy IDs… reversing the import dependency seems reasonable.