@angular/localize should have @babel/core as a devDependency

🐞 bug report

Affected Package

@angular/localize

Is this a regression?

not sure

Description

@angular/localize has @babel/core as a dependency, and not a devDependency.

We use BlackDuck for all the license attributions for the code we ship, but because @babel/core is include here, all the @babel/* and dependencies show up for BlackDuck to generate a report on, and include in our distributed license file even though none of that is browser code that will be shipped to users.

🔬 Minimal Reproduction

• Create a new project: ng create new-project
• Add @angular/localize: ng add @angular/localize

[JoostK]

@JoostK Thanks for clearing this up! Maybe long-term it makes sense to split @angular/localize into different packages? Given that the default way to install it is via schematic, both could be installed (in their appropriate category) anyway.

@Airblader Yeah, the way to go about it needs some discussion. Splitting could be one option, although I think it makes more sense to move the tooling part of @angular/localize into @angular/compiler-cli (which is already a peer dependency of @angular/localize). But there’s possibly more alternatives, such as optionalDependencies (I’m not sure whether that could work, nor how e.g. license extraction tooling deal with optional deps).

[JoostK]

This is an interesting one. The proposed solution of listing @babel/core only as a dev dependency would not work, unfortunately. Doing it like that may result in @babel/core being unavailable, as dev dependencies are not installed in consuming projects.

This situation occurs because @angular/localize includes multiple targets: the localize runtime and the localize tooling. The latter needs the @babel/core dependency, whereas the former does not. Tooling dependencies typically go into a project’s dev dependencies, such that the license extraction tool works correctly. In this case, however, it’s typically a dependency of the project because of the runtime part.

I think you could workaround by changing @angular/localize into a dev dependency of your project. When building the project, the runtime parts of @angular/localize will be included in the build output so it should be okay not to list @angular/localize as a real dependency. The only potential issue with this could be with libraries when its consuming application does not depend on @angular/localize, as then the true dependency on @angular/localize will get lost.