please release babel files as @ngtools/babel

[sod]

With build-optimizer being deprecated now, having to install @angular-devkit/build-angular with a rather chunky dependency tree - nearly all depedencies pinned to a specific version - is unfortunate.

Do you plan to release https://github.com/angular/angular-cli/tree/master/packages/angular_devkit/build_angular/src/babel as @ngtools/babel just like @ngtools/webpack? Or as @angular-devkit/build-babel in the vein of @angular-devkit/build-webpack.

[dgp1130]

Hi @sod, @angular-devkit/build-optimizer is not really considered a public API. It's experimental on NPM (not yet 1.0.0) and is effectively an implementation detail of the Angular CLI. The extra package wasn't really necessary, so we folded it into @angular-devkit/build-angular since the only supported usage is through the CLI itself. Refactoring this directory out of @angular-devkit/build-angular and into another package is just making it easier for users to depend on private implementation details which could change in the future.

If users really want to depend on these private APIs anyways, they can deep import from @angular-devkit/build-angular. The package is bigger than it needs to be for that purpose as you mentioned, but that is the nature of leveraging private APIs. Even then, we may end up adding Node.js exports in the future, which could break deep imports as well. The most maintainable solution would probably involve forking the repository and deleting the unnecessary pieces or vendoring the NPM package and altering it to meet your needs.

I think the more important question is about your actual use case. Is there something in particular you're trying to do that requires this package? Problems like optimizing Angular output for production builds are exactly the kind of things the CLI is intended to solve. Is there a reason you can't use the CLI and need to directly leverage these private APIs?

[sod]

your actual use case

Build angular without the cli.

I don't want to have to install an npm kitchen sink (speaking of @angular-devkit/build-angular) to be able to even run angular in node.js for tests.

[sod]

forking the repository and deleting the unnecessary pieces

Thats kinda what I do right now.

As copying those 7 source files into our project is way less burden then adding @angular-devkit/build-angular to our dependency tree. And as that copy was rather easy, thats why I created this ticket, if you intend to create a distinct package for it.

[alan-agius4]

your actual use case

Build angular without the cli.

I don't want to have to install an npm kitchen sink (speaking of @angular-devkit/build-angular) to be able to even run angular in node.js for tests.

But what is your use-case of not wanted to build your application using the Angular CLI in the first place? You would still need to install most of the dependencies of @angular-devkit/build-angular to build and optimize an application without the Angular CLI.

More over, without the Angular CLI, you will be missing out on other things considering how complex Webpack configuration can be, the CLI also has other improvements such as using a combination of ESBuild and terser to performance CSS and JS minification, deduplication of duplicate modules, forces SASS/SCSS compilations to be sync because async compilations can be 2x as slow etc..

[sod]

considering how complex Webpack configuration can be

I like webpack. And putting @angular/cli in front of webpack doesn't make it less complex. Especially if I got a build issue at hand and now have to battle webpack + the facade on top.

You would still need to install most of the dependencies of @angular-devkit/build-angular to build and optimize an application

Thats not true. I cobbled together a minimum viable angular@13 build:

package.json https://github.com/sod/angular-webpack/blob/master/packages/build/package.json
webpack.config.js https://github.com/sod/angular-webpack/blob/master/packages/build/webpack.config.js

Of course the 7 babel & build-optimizer files copied into the reproduction, as the purpose of this ticket to have those published separately.

[dgp1130]

Beyond @alan-agius4's points, one of the biggest challenges with this kind of use case is that it is significantly harder for the Angular team to provide support and minimize breakages, especially around our ng update tooling. Any necessary alteration to the build becomes a breaking change which is infeasible for us to fix automatically and results in a lot more churn for users (especially those who may not understand Webpack as well as you do).

Were there any technical reasons for choosing this format, or does it mostly come down to your existing knowledge of Webpack and wanting to have more control/transparency into how your build works under the hood?

[sod]

I don't wanna waste your time. If publishing those 7 files as a distinct package isn't feasable, then I'm fine with copying them into our project. Thank you for answering.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}