fix(@ngtools/webpack): replace resources should effect only class dec…

[alan-agius4]

Replace resources should effect only class decorators

At the moment we are processing all property assignments in object literals irrespective if they are in a decorator or not. With this change we will process only property assignments found under a class decorator.

Fixes #12488, Fixes #6007, Fixes: #6498 and Fixes: #8295

[filipesilva]

Hm this is a tricky one. Pretty sure some usecases are going to be broken by this. Like consts outside of the decorator that compose properties.

But I kinda think we should reduce the magic we do, and be more clear about it. It's not intuitive at all that that things can break by having a templateUrl property anywhere. I'm pretty sure this ended up causing some AngularJS templates to also be processed, for instance.

Adding the discussion label to make sure everyone is onboard with the direction.

Personally I think this PR should go in, and enhanced with some information about the magic we do in a readme, either CLI or ngtools/webpack (or both). Stuff like "templateUrl and stylesUrl will be processed if found within decorators, loadChildren will also be processed and should have a relative path or from the tsconfig baseUrl".

[alan-agius4]

We can also do an addition checks that we only process Component decorators from `@angular/core. But that would incur that we need to get the import clauses and check their symbols because of various usecases.

Ex

import { Component as NgComponent} from '@angular/core'
import { Component } from '@angular/core'
import * as ng from '@angular/core'

[clydin]

Feel free to resurrect all or part of this old PR: #8401

[alan-agius4]

@clydin thanks, ill continue this tomorrow. that getDecoratorOrigin is will be pretty useful :)

[alexeagle]

/cc @alxhub - this seems related to how the AOT compiler works - but in this case we need to do some transform for JIT

Also related to how we'd like to get away from JIT mode altogether when Ivy is just a tsc plugin

[alxhub]

FWIW, Ivy requires that component metadata be inlined into the decorator.

Personally, I think this PR should land. You already don't support the full capabilities of ngc today. For example, this is totally valid:

import {templateUrlFor} from './templates';

@Component({
  templateUrl: templateUrlFor('some-component'),
  ...
})
export class SomeComponent {}

...

// templates.ts:
export function templateUrlFor(name: string) {
  return `../templates/${name}.ng.html`;
}

Trying to support all of this and resolve metadata in the same ways that ngc does would be infeasible.

[filipesilva]

Especially like all the new tests 👍

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