[typescript-angular] drop support of angular below 6.0.0

[macjohnny]

Remove support for old angular versions below 6.0.0, allowing to clean up the code base.

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

cc @TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @topce (2018/10) @akehir (2019/07) @petejohansonxo (2019/11) @amakhrov (2020/02)

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[amakhrov]

Great job @macjohnny !
All looks good to me.

I only have one question re string enums.

Should we preserve some way to emit enums in namespaces?
With real string enums it's the only way to make two structurally identical enums inter-assignable. Which can be a handy workaround for OAS2 limitation (which doesn't allow to re-use a enum and requires to redefine enum for every field).

Example:

Query1:
  properties:
  - sort:
    type: string
    enum: [asc, desc]

Query2:
  properties:
  - sort:
    type: string
    enum: [asc, desc]

It emits two enums:

enum Query1SortEnum {
  asc='asc',
  desc='desc'
}

enum Query2SortEnum {
  asc='asc',
  desc='desc'
}

In TS, enums are not assignable to each other even if structurally compatible. So I can't do this:

let q1!: Query1;
let q2: Query2 = q1;

However, namespaces solve that. If the same enum (with the same name!) is defined in two different namespaces, TS allows assigning one to another. That's what we do in our project currently (with tweaked mustache templates)

namespace Query1 {
  export enum Sort {
    asc='asc',
    desc='desc'
  }
}
namespace Query2 {
  export enum Sort {
    asc='asc',
    desc='desc'
  }
}

Previosuly, with stringEnums=false (default) it was not an issue at all, because they were not real enums.
Now we always emit enums, which can introduce this TS issue with OAS2-compliant specs.

Any thoughts?

[TiFu]

This raises a philosophical question: Do we want to fix the shortcomings of OAS2 with an implementation that tries to be smart?

In the case that you described, what happens if a new enum value is introduced only for Query2SortEnum (let's say random)?
Does TS still allow what you are trying to do or would this potentially cause errors totally unrelated to the actual change in the spec?

[amakhrov]

Does TS still allow what you are trying to do or would this potentially cause errors totally unrelated to the actual change in the spec?

You will be able to assign Query1SortEnum values to variables of type Query2SortEnum but not vice versa.

Do we want to fix the shortcomings of OAS2

I'm not a big proponent of that approach. I mostly wanted to point out that the change in the PR can have backward-incompatible outcome without a fallback even for angular 8/9 users.

On the other hand, e.g. axios generator has never had such stringEnum option - it just always emits enums. We can stick to this approach for consistency across typescript generators.

[wing328]

If it's a limitation only with OAS2, then I would suggest asking users to migrate to OAS3 spec instead.

[macjohnny]

In order to minimize the breaking changes, I decided to revert the changes related to the string enums, since the functionality is already implemented and not too much of a burden.