Expose Webpack Configuration

[yjaaidi]

🚀 Feature request

Description

In order to integrate Angular with some external tooling like Cypress Component Testing, it is necessary to provide a webpack (or any other building tool) configuration.
While AngularCompilerPlugin is a really good start, it doesn't cover the whole magic happening under the hood of @angular-devkit/build-angular. This needs us to create a custom webpack config using the AngularCompilerPlugin.

Describe the solution you'd like

Even though Webpack is kind of an Angular implementation detail, it would be a dream come true to expose a function like ɵresolveWebpackConfig({target: 'my-app'}) that could be inspired from:

angular-cli/packages/angular_devkit/build_angular/src/dev-server/index.ts

Lines 99 to 104 in f6135a2

	async function setup(): Promise<{
	browserOptions: json.JsonObject & BrowserBuilderSchema;
	webpackConfig: webpack.Configuration;
	projectRoot: string;
	locale: string | undefined;
	}> {

I understand that this would considerably extend the public API's surface and that is why I am totally alright if we could start some experiments with a non-public function (hence the ɵ).
https://github.com/jscutlery/test-utils/blob/ec422695e9de3ecfa560143098bda6198756e860/packages/cypress-mount-integration/src/plugins/index.js#L6-L40

Describe alternatives you've considered

Creating a public library exposing a webpack config that mimics @angular-devkit/build-angular behavior.

If you are OK with the idea, I'd be happy to help.

[yjaaidi]

Cc. @kyliau

[alan-agius4]

Hi @yjaaidi,

Any reason why not use the architect API to build the application?, Example:

angular-cli/packages/angular_devkit/build_angular/src/protractor/index.ts

Lines 107 to 108 in b34ed5c

	const target = targetFromTargetString(options.devServerTarget);
	const serverOptions = await context.getTargetOptions(target);

I think realistically exposing the entire Webpack configuration will not be ideal. Here are some reasons.

• The structure of the Webpack configuration changes quite a bit sometimes even in patches.
• The Webpack configuration is very dynamic and is generated based on a large set of options.
• I think having it as a public API, will be a limiting factor on the CLI as we couldn't easily amend it without causes breakages downstream.

[yjaaidi]

Hey @alan-agius4, thanks for this ⚡️ lightning-fast feedback ⚡️.

The main reason for this situation is that the way cypress component testing works is using all spec files as entry points that it lazy loads one by one depending on the tests you want to run.

Here is the startDevServer function that overrides the given webpack config:
https://github.com/cypress-io/cypress/blob/56234e52d6d1cbd292acdfd5f5d547f0c4706b51/npm/webpack-dev-server/src/startServer.ts#L17-L25

I can only see 3 options:

1. exposing the webpack config
2. custom webpack config (as mentioned before)
3. passing lots of new options to the target (e.g. entry points)

Am I missing any better option?

Concerning the first option, I don't think that the function has to be part of the public API. It should be used with the following condition: the webpack configuration returned by the function will only be compatible with the exact same version defined here https://github.com/angular/angular-cli/blob/master/packages/angular_devkit/build_angular/package.json

The main purpose of this function is to provide an easy way of hacking the configuration for extreme use cases like this one.

In general, I'd rather use a "use at yɵur ɵwn risk" piece of API than mimic the webpack config as it seems to be the only option.

[lmiller1990]

Hi, I work on component testing at Cypress. Happy to answer any questions or do any work that might help move this forward.

Ideally I'd like to test my Angular components with Cypress using the exact same configuration used by Angular CLI (via ng serve, for example). We do something similar for our other integrations - we grab the webpack config for Next.js, CRA, etc.

Sometimes it's easy, like with CRA. On the other hand, much like Angular, Next.js's webpack config is dynamic and changes a lot, and not officially "public" (eg, it's not documented) so it's "use at your own risk". I think something similar might work for Angular.

[ocombe]

@lmiller1990 wrote:
Ideally I'd like to test my Angular components with Cypress using the exact same configuration used by Angular CLI (via ng serve, for example). We do something similar for our other integrations - we grab the webpack config for Next.js, CRA, etc.

I work on the Angular integration for bit.dev and we need the same thing, being able to programmatically run the angular dev server (which means that we can't really use the CLI and builders).
If there is no other alternative I will try to recreate the angular webpack config, we can probably make that in a public repository so that it helps other people as well. Any help would be appreciated because it's probably going to be a lot of maintenance.

[yjaaidi]

For those who are interested, we (@jscutlery) managed to hack our way like this:
https://github.com/jscutlery/test-utils/blob/main/packages/cypress-angular-dev-server/src/lib/create-angular-webpack-config.ts#L13-L69

We could expose this function through a library if lots of people show interest.

It's not perfect but IMHO, it's way better than writing and maintaining an Angular webpack config from scratch.

As mentioned here jscutlery/devkit#51, we are planning to add a target option which defaults to the default project's build in order to grab settings from angular.json or Nx workspace.json (e.g. styles, polyfills, etc...).

🙏 special thanks to @alan-agius4 for your help!

cc. @ocombe @edbzn

[lmiller1990]

Nice job! This seems like a good enough work around for now - definitely better than maintaining a separately and fairly complex webpack config.

I think a lot of people would appreciate a little helper library they can use for this! Just need to make sure there is a disclaimer that this uses undocumented internals, etc.

[alan-agius4]

Hi all,

Thanks for all your input. We have discussed this issue in depth during yesterday team meeting and we feel that exposing the Webpack configuration is something that we don't want and want to keep this as private as possible.

There are a number of reasons why we think that exposing the webpack config is not a good idea, below are some of these;

• We don’t provide semver guarantees and this config might break/change in any version include patches.
• We don't guarantee that we stay on Webpack forever. The fact that we use Webpack is an implementation detail.
• Replacing Webpack should cause little no friction to ECO system and using Angular CLI directly or indirectly.
• To generate a Webpack configuration, a large set of options needs to be providing including the builder context.
• Webpack specific features are not supported.

Therefore we feel that;

• if you or your tool uses Webpack directly, the best course of action is to create your own configuration and tailor it to your needs.
• Implement logic similar to ng e2e for Cypress https://github.com/cypress-io/cypress/tree/master/npm/cypress-schematic and using the Architect API spin up the dev-server.

[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.}