build: restructure demo-app in favor of bazel

[devversion]

Restructures the demo-app by no longer mixing up the demo-app name.

Currently the demo-app consists of two parts:

• The demo-app
• And the accessibility demos

As you can tell above, this is pretty much confusing because it's
technically just consisting of:

• Accessibility demos
• Library demos

This change cleans up the naming and makes sure that the modules are
structured in a best-practice way.

It's odd to have the DemoAppModule (not the root module) that
includes all library demos as a folder next to the actual demo
components.

This makes it extremely hard to convert the demo-app to Bazel because
we cannot target all .ts files through glob because it only matches
files inside of the same folder (or Bazel package).

In order to make it easy to run the demo-app with Bazel, and to just
clean it up, the folder structure should be as followed:

src/a11y-demo/
  | ...

src/dev-app/
  | ${DEMO_COMPONENT}
     | ...
     | BUILD.bazel
  | index.html
  | BUILD.bazel

[devversion]

@jelbourn We can chat more about why this is needed, in case you have any questions.

Moving forward, it's just unavoidable to somehow clean up our demo-app because right now, it's just feels unstructured, confusing, and not really Bazel compatible.

Also I'm not entirely sure about the name library-demos. I'm really open to other names or even another approach

[crisbeto]

Wouldn't it be better to completely split the a11y app from the demo app? That's what we're doing for the e2e app anyway. I don't think there's any reason for them to be together, apart from sparing us a main and app.module file. E.g.

src/
  | a11y/
     | ...
     | BUILD.bazel
     | index.html
  | demo-app/
     | ...
     | BUILD.bazel
     | index.html

[devversion]

That works too, and I considered it as well, but I just was afraid of re-adding another gulp process for the a11y app which should probably also include a watch mode, and build configuration.

I'm fine doing so though. We can also just have the a11y app as a plain Bazel package. While it would still take some time to actually serve it with Bazel, we could already build it like that without having more gulp tasks.

I suppose nobody is currently spending a lot of time on the a11y demos anyway.

[jelbourn]

Yeah, I would prefer splitting out the a11y app into a separate thing. Also, since it's such a big change anyway, renaming demo-app to dev-app.

[devversion]

@jelbourn That's reasonable. Should we still add gulp tasks for the a11y stuff or rather just use Bazel for building (as mentioned above)?

[jelbourn]

We can just do the bazel setup for now since nobody is actively using the a11y demos at the moment

[devversion]

Sounds good. That's what I was hoping. I will make the changes as soon as possible.

[ngbot]

Hi @devversion! This PR has merge conflicts due to recent upstream merges.
Please help to unblock it by resolving these conflicts. Thanks!

[devversion]

@jelbourn I've updated the PR.

[jelbourn]

To clarify: the intent of this change is to make it possible to run the dev-app via bazel, which will be a follow-up, right?

[devversion]

Exactly. There are a few more blockers for actually building the dev-app with Bazel, but I'm working on fixing those (e.g. angular/angular#27062)

This PR should be ready for review.

[jelbourn]

LGTM

[devversion]

@andrewseguin This one is rebased now as well.

It's just red because of the API guardian tests. Those should be fixed with #14144.

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