Update to Angular 19 with rework

[joematthews]

update to angular 19 with rework

view new repo/README.md: https://github.com/joematthews/extreme-angular/tree/update-to-angular-19-with-rework

Draft changelog:

What's Changed

---

Configuration Changes

• Update to Angular 19 (and rework config to match @angular/cli generated output)
• Switch all .js config files to ECMAScript Modules (special thanks to @replete for this change)
  • Add "type": "module", to package.json
• Add new scripts to package.json:
  • lint:spelling: check spelling in all files
  • lint:tsc:app: check for Typescript errors in application files
  • lint:tsc:spec: check for Typescript errors in spec/test files
  • lint:format: silently check formatting in all files
  • lint:all: run all lint scripts
  • ci:all: run lint:all and test:ci
  • shove: quickly add, commit, and push all files without checks or tests (for quick back up in case of emergency)
• Add on-pull-request.yml and validate-code.yml Github Action workflows.
  • Run ci:all script in pre-push hook and validate-code.yml workflow.
• Add /.husky/_ to .gitignore to prevent false negatives when running lint:format
• Add dictionaries to .cspell.json to help reduce false negatives
• Print 'Example conventional-commit messages' on commitlint failure
• Adjust .editorconfig to make it easier to match indent_size with Prettier tabWidth
• Remove @angular/material, @angular/ssr, and @angular/localizeschematics.
• Remove commitizen and configuration.

README Changes

• Improve wording
• Add new sections:
  • Shove Progress
  • Continuous Integration (CI) Using GitHub Actions
  • Optional Angular Schematics:
    • Angular Material & Angular CDK
    • Server-side & hybrid rendering (SSR)
    • Internationalization (i18n)
    • End to End Testing (e2e)
      • Include Playwright eslint configuration example.
  • Tips & Tricks:
    • Custom Formatting
    • Git Config
    • Oh My Zsh / Oh My Bash / Oh My Posh
    • JetBrains IDEs

[joematthews]

@replete I based this PR branch off of your PR branch, although I'm not too sure how many of your lines are left except the # Extreme Angular 19 in the README.md

Can you look things over? Your feedback is very much appreciated. Thank you. 🙏

[joematthews]

Marking this as draft. Going to continue to refine the README package.json scripts.

[replete]

Hi @joematthews
I made some changes in this new branch in my fork, it's based on this current PR so should replay if you want to bring it into this PR:
https://github.com/replete/extreme-angular/tree/use-more-esm-in-tooling

The main change is to adopt ESM and drop CommonJS as primary standard in the tooling. I think we're at a place now where we'd all be happier with just one flavour of modules in the JS ecosystem, and its mostly there.

Changes in branch:

• set "type": "module" in package.json - this means that the .js extension will be assumed ESM. If we really need commonJS, we can use .cjs. .mjs is only required in projects where type:module is not set in package.json. I think this is best practice nowadays as commonjs becomes legacy.
• convert and rename eslint.config.js to ESM:
  • The rename to .js is parity with type:module being added
  • I've also renamed some of the imported objects for more precision on what they are - this kind of thing really helps when projects grow. I would have pulled { configs as esConfigs } for the eslint/js, but its apparantly a commonJS module, which is really weird, so we can't do that without eslint falling apart. A compromise
• add .js single quote rule to .editorconfig and reformatted eslint config file for consistency
• adopted globals.node etc instead of { node } for the globals packages - node prettier aren't great names in terms of potential conflicts, and don't represent what they actually are. We could have done `{ node as nodeGlobal, ... } etc, but would be unnecessarily terse, and globals.whatever is already very clear what it is. This is a principle I've found really important in shared codebases - name the thing very closely to what it is

See what you think, but this is something I'd want in any modern project, make everything ESM and use .cjs if I really have to. Most popular toolings now support ESM, and that's the standard now so why not.

The other thing that bugs me that as a user of this package, is the 2-space indent on JS/TS source, I personally find it less readable, but of course its subjective, but it doesn't seem as good as 4 to me generally. Again, not a big deal for an end user would just change it and fix all, and if its good enough for airbnb. Well, it is an interesting point though, I see the benefit of more code being visible, but it just seems for most people harder to read? I wonder if there are any surveys on this... either way genuinely not a big deal for me. EDIT: I'm going to build my next project in 2sp and see if I get used to it

[joematthews]

I couldn't agree more. I only stuck with CommonJS for eslint.ocnfig.js because that's what angular-eslint produced -- but as I got more and more annoyed when incorporating libraries in to the config.

Switching to ECMAScript modules will also make it possible for prettier-plugin-organize-imports to do it's magic in config files too.

I'll checkout your branch very soon.

[replete]

I did notice the automatic import organizing after I ported eslint config to ESM. Very nice!

If these changes make it in will need an update in README.md for the playwright code sample, have to pop out for the rest of the day but will have a look what's happening tomorrow.

[joematthews]

The other thing that bugs me that as a user of this package, is the 2-space indent on JS/TS source.

I get it. Hot topic. I don't disagree about the readability. I am used to it at this point.

I think it's best to keep 2 character indentation for these reasons:

• Angular documentation and the angular project itself uses 2 spaces
• Prettier defaults to 2 spaces
• 4 spaces can look pretty bad in JS/TS sometimes with an 80 character line limit
• 2 space indention is traditional for various reasons

Aside from all that, for me personally, I really like the ability to do side-by-side editors and in my experience that really sucks in JS/TS unless indentation 2 and the line width is 80.

All that said, I have have become quite used to Prettier's output for files, but I do remember saying 'ewww' out loud the first time I formatted all files in a project hah.

Changing the indentation and line width is pretty easy. In the .editorconfig set the desired indent_size in the overrides for the desired file types:

[*.ts]
quote_type = single
indent_size = 4
ij_typescript_use_double_quotes = false

And then in the .prettierrc.json file set the tabWidth & printWidth to your desired values:

{
    "tabWidth": 4,
    "printWidth": 120,
    "htmlWhitespaceSensitivity": "ignore",
    "plugins": [
        "prettier-plugin-sh",
        "prettier-plugin-css-order",
        "prettier-plugin-organize-imports"
    ]
}

And run npm run format, then review, and commit the results.

Should I include these instructions in the tips and tricks? 🤔.

[replete]

Hi Joe, I probably didn't need to think out loud there, I did notice the angular docs after writing the comment. I will adapt and I suspect end up liking it...

[replete]

What would be really extreme, would be forcing tabs, which would let anyone display their code however they want 🤣

After contracting for some years, I learned that tabs are not a hill worth dying on...

[joematthews]

Hi Joe, I probably didn't need to think out loud there, I did notice the angular docs after writing the comment. I will adapt and I suspect end up liking it...

No, it was important to bring up! It has come up in every team I've been on when setting up Prettier. Some teams have opted for longer line widths and using double quotes in TS files. But, I will admit, I've talked them all out of 4 spaces! haha

Not using tabs was historically a missed opportunity. But there can be conflicts between editors that expect spaces. The .editorconfig file can help a lot, basically instructing the editor's default behavior (if they have a plugin for it).

If you want to try out tabs, you can look at the useTabs option for Prettier. This will allow the pre-commit to reformat changes correctly with tabs before commit (no matter what other devs are doing in their editor).

That's the beauty of prettier --write in the pre-commit. Doesn't help if they do commit --no-verify though 😞 That's where formatting checks in pre-push and in CI can help.

[joematthews]

@replete I merged in your changes. Thank you very much!

The only fix I did was reverting the files proprety in the jasmine section to 'src/**/*.spec.ts' so they do not conflict with potential 'e2e/**/*.spec.ts' files if they opt for playwright. (this was something I corrected for earlier in my barrage of pushes lol)

[replete]

Awesome, it's looking tidy! I'll test the new setup again when it all lands in main with a new project next week.

I'm churning through trying to figure out best practices for all the 'new' Angular stuff – all the books I'm reading on this are still mostly for Angular 17 and it seems to me like zoneless + signals are a direction I should be headed, but there'll be some lag I guess with best practices so it feels like early days with all that.

[joematthews]

@replete yeah, I'm pretty new to both zoneless and signals myself.

I have a few projects coming up and I think I will keep zonejs (for now) and use signals more (or exclusively if possible).

In the zoneless docs it mentions using OnPush to be safe. In the new eslint.config.js I'll probably be setting this to 'error' in my projects, so it enforces onpush for every component:

      '@angular-eslint/prefer-on-push-component-change-detection': 'off',

I don't want to make this 'warn' or 'error' by default quite yet in extreme-angular because it will conflict with the documentation.

[joematthews]

@replete

I removed the serve:ssr:extreme-anglular script from the package.json since (because ssr is no longer installed), and update @angular/cli & @angular/core to 19.1.1 (I think you mentioned it was out of date but I misunderstood).

I'm going to start working on release notes (I'll use the description of the PR as a scratch pad). Any thoughts come to mind?

[joematthews]

@replete I fixed some last minute things I noticed while reviewing the diff and creating the change notes. I'm going to go ahead and pull the trigger on the release.