[Feature request] Ability to serve and run tests against pre-compiled output directory

[itslenny]

There is currently no way to serve the site (or run tests) against the result of a previously executed ng build. This is problematic for a few reasons explained in detail below.

This is a continuation of the discussion started here: #4975

ATTN: @johnpapa / @filipesilva

Motivation

• Consistency - There are some inconsistencies between ng serve and what ng build places in the dist folder. For instance, ng serve serves everything in the root of the src directory which means that static assets can be loaded from src that will not be available after deployment.

• Debugging - Sometimes it's useful to be able to serve the app exactly as it will be deployed. I've used this when debugging AOT related issues that only present at run-time in a production build. There are other options for this scenario, but running simple http server in the dist folder was the easiest option, but I think ng-cli should be able to use it's included server for this instead of me needing to use another http server.

• Deployment pipeline - currently my continuous deployment is building the app 3 times. Once each for ng test, ng e2e, ng build. Ideally I could run ng build then run the tests against the code in the dist folder.

[filipesilva]

Before discussing anything else, I would like to mention that your first point was true a while ago, but has since been fixed in #4691. So files in ./src are not served unless they are truly part of the build.

[filipesilva]

I agree that there is a need for this sort of functionality, but not as far reaching as you propose.

Unit testing is not a real scenario in my opinion. Build code does not include unit tests, and it doesn't make any sense to try and run outside unit tests over already built code.

The e2e scenario is also a minor issue since you can disable serving via ng e2e --no-serve. After that you can configure a different baseUrl for protractor and it will test whatever you point it at. Admittedly, we don't offer --baseUrl flag but you do offer a --config flag instead to use a different config file.

So as long as you can serve the built version somehow, you can e2e test it right now.

So that leaves us with the matter of consistency and debugging 'real' builds.

You mentioned running a simple http server. But you must agree that is a poor simulacrum of your real server. The only real point of commonality are that it serves files somehow. So the need for consistency is not being fulfilled, and the debugging one only partially.

I think that the very least such a server would need is:

• the real host (not localhost)
• --deploy-url and --base-url to match your build
• proxies (if you use them via --proxy-config)
• fallback configuration (as described in https://angular.io/docs/ts/latest/guide/deployment.html#!#fallback)
• the same routing rules as your real server
• a ssl cert if used

So I argue that simulating ones real server with fidelity is not just a matter of firing up a simple http server.

That is not to say this isn't a real need. It is. And if we had this, there would be a lot of problems that would be caught before the app is deployed somewhere.

So I would like to see such a command in the CLI in the future. Something like ng serve --dir=./dist or ng serve-build. But it needs to be a high-fidelity simulation.

[itslenny]

I'm actually running ngServe with most of the criteria you listed today (custom host name, ssl cert, same routing, fallback) this is needed because our app has an oAuth scenario that requires https and a valid hostname in the callback URI.

I'm using IIS in production (I work at Microsoft btw) so I'm happy with just a similar enough http server for e2e tests, and honestly the web pack dev server does fine. We also have a staging deployment and flighting / rollback so the e2e's are just the first line of defense.

I suppose given the criteria you mentioned it might just make more sense to not even use ng to spin up the server because everyone will have their own production server story so building the app then running your own server for E2Es and local prod-like testing makes more sense.

[DavyDeDurpel]

I would like to add an argument. I'm fond of VS Code because it has some great remote debugging possibilities. With the current version of the cli this is no longer possible as the .map files only exist in memory and VS Code needs them physically.

[kfrooney]

I agree for all of the reasons stated above.

Most compelling to me is the reduction of unnecessary work on CI builds.

In addition, the issue about running against a production-like environment isn't so much about running against the real deployment environment, as it is running against the code that you actually intend to deploy to your server, to then be served to your client (we are, after all, testing client applications that a dumb server just serves up).

When something odd happens in an e2e build, there's little ability to truly introspect what the test is running against, short of obtaining a whole separate environment and deploying code (this is difficult in corporate environments where setting an environment up and/or sharing environments for different purposes, i.e. mock or instrumented code, can be a huge pain in the neck).

Another use case is that doing things like instrumenting code for coverage details before a one-off test run, or as mentioned above, editor configuration, becomes much simpler.

Free the compiled assets :-D!

[GO3LIN]

I am very surprised that there's no option for the ng test command to test against an already built app. The main motivation for me is reducing CI build time too as @MonkeyIncinerator noticed.

Is there already someone working on this topic ? I can be a volunteer in case

[Iverson]

Is there any plans to solve that problem?

[giggio]

To me the most important problem to solve is testing. ng test tests one thing, and what we later run in production comes from ng build. This breaks a basic rule of consistency. Our builds are not trustworthy. We don't know if we tested what is actually in production. It could be something else.
Also, the total build time increases, as we build twice, once for the test, and another for the actual build.
And the test time increases as well, as there is a lot of compilation happening during testing, which we could already had ran with aot.

[markus-heinisch]

Hi, is there any progress on this topic?
I'm working on a project where we have to prove that our binary (aka a docker image containing an Angular app on nginx) is tested (using ng test). We can't build a binary, test a second binary (build by ng test) and then promoting the first (untested) binary to the next stage in our CI/CD.
Any ideas? - Thanks, Markus

[TroelsWibergJensen]

To me the primary motivation here is to avoid building twice on CI server, but the added benefit of testing on the same compiled output is compelling as well 😄
Can we get a status on this request?