Command

serve

Is this a regression?

• [ ] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

Component ID generation collision detected is thrown after first change when running default angular installation

Minimal Reproduction

1. npm create @angular@next
2. Choose ssr to be enabled
3. ng serve
4. change app component html -> no warning
5. change app component html again -> warning is shown in console

Exception or Error

No response

Your Environment

Angular CLI: 17.0.0-next.6
Node: 18.17.0
Package Manager: npm 9.6.7
OS: darwin arm64

Angular: 17.0.0-next.6
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, platform-server
... router, ssr

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1700.0-next.6
@angular-devkit/build-angular   17.0.0-next.6
@angular-devkit/core            17.0.0-next.6
@angular-devkit/schematics      17.0.0-next.6
@schematics/angular             17.0.0-next.6
rxjs                            7.8.1
typescript                      5.2.2
zone.js                         0.14.0

Anything else relevant?

No response

This commit clean ups the compiled components state when the build is being executed in watch mode. This is required as otherwise during development Component ID generation collision detected are displayed on the server.

Closes: #25924

Safari 15 is still support but not by default. Users needs to opt-in by adding it in their browserslist config.

fix: santize noscript contents

Previously, noscript was parsed as raw text. This however is not correct as noscript can contain child elements. We no updated the logic to parse noscript as an element which causes santization of child nodes.

fix: escape angle brackets in attribute value

Angle brackets inside attribute values are now escaped, This is to ensure unsafe behaviour after de-serialization.

Good catch

Something like

  /**
   * Constructs a `POST` request that interprets the body as JSON
   * and returns the response body as an object parsed from JSON.
   *
   * @param url The endpoint URL.
   * @param body The content to replace with.
   * @param options HTTP options
   *
   * @return An `Observable` of the response, with the response body as an object parsed from JSON.
   */
  post(url: string, body: any|null, options?: {
    headers?: HttpHeaders|{[header: string]: string | string[]},
    context?: HttpContext,
    observe?: 'body',
    params?: HttpParams|
          {[param: string]: string | number | boolean | ReadonlyArray<string|number|boolean>},
    reportProgress?: boolean,
    responseType?: 'json',
    withCredentials?: boolean,
    /** Enable .... */
    transferCache?: {
      /** Specify ... */
      includeHeaders?: string[]
    }|boolean

  }): Observable<Object>;

@JeanMeche, can you please use fixup commits?As it’s easier to see what changed after a review. As otherwise, I will have to review the whole thing again.

You need to do the docs, as part of the inlined typed in the init.

Probably would make sense to have a shared interface to avoid duplicating comments.

Can create an example later as I am currently commuting.

I am not really understand the point about PUT and DELETE. I am asking solely POST.

If on a POST request, transferCache is set enabled, it will still not be cached without the global flag enabled, but this means that now users would need to find all other POST requests that don’t/shouldn’t be cache and disable caching for them.

IMHO, if caching is enabled on a POST request, the global flag doesn’t need to be set to enable caching. At least, I find it more intuitive from a user POV.

//cc @AndrewKushnir

Umm.. in that case though getAll should still be logged as this method doesn’t return all headers but rather all the values of a specific header.

PR Checklist

Please check to confirm your PR fulfills the following requirements:

<!-- Please check all that apply using "x". -->

• [x] The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

<!-- Please check the one that applies to this PR using "x". -->

• [x] Bugfix
• [ ] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Documentation content changes
• [ ] Other... Please describe:

What is the current behavior?

Currently, running a schematics that adds @types/node to a project, like ng add @angular/ssr, will add the v16 types.

What is the new behavior?

As nodejs v16 is now EOL, this PR updates the types to v18.

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

<!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. -->

Other information