@edusperoni this might not be exactly what you're looking for since my workflow is specifically for working on the docs, but does this help you? My workflow

This sounds like a duplicate of #31908.

@kapunahelewong Unfortunately not exactly. Let me try to rephrase it:

Say I want to change code in @angular/core. Ideally I'd open a test application, change packages/core/src/refs.ts and it would automatically refresh this application with my changes.

Rebuilding all npm packages is an option, like what is suggested on #31908, but that seems way too heavy (multiple bundle generation every change and having to call the whole build again instead of running in watch mode), considering ibazel build //packages/core runs in a small fraction of that time.

I guess if I'd rephrase it into a question, it'd be: If I want to make a change to an angular package, how should I setup my dev environment so I could "test" (not unit/e2e testing) those changes?

Hey, that sounds a lot with what I've been up to recently. I'm happy to say that it finally works for me. If you can build packages localy on your machine "@angular/common": "file:../../angular/dist/packages-dist/common", might (/will?) be the quickest way since you can have bazel in watch mode.

Unfortunately though this only works on limited packages for me. E.g. including core & common is fine, but forms and module fail on unresolved dependencies.

In case you happen to struggle with peer dependencies (they're crucial!), just add them like so:

  "dependencies": {
    "@angular/animations": "~7.2.0",
    "@angular/common": "~7.2.0",
    "@angular/compiler": "~7.2.0",
    "@angular/core": "~7.2.0",
    "@angular/forms": "~7.2.0",
    "@angular/platform-browser": "~7.2.0",
    "@angular/platform-browser-dynamic": "~7.2.0",
    "@angular/router": "https://123456-123456-gh.circle-artifacts.com/0/angular/router-pr12345-1a2b3c.tgz",
    "core-js": "^2.5.4",
    "rxjs": "~6.3.3",
    "tslib": "^1.9.0",
    "zone.js": "~0.8.26"
  },
  "peerDependencies": {
    "@angular/core": "7.2.15",
    "@angular/common": "7.2.15",
    "@angular/platform-browser": "7.2.15",
    "@angular/compiler": "https://123456-123456-gh.circle-artifacts.com/0/angular/compiler-pr12345-1a2b3c.tgz",
    "zone.js": "0.10.2",
    "rxjs": "~6.3.3"
  },

An alternative is using artifacts from circleci - and yeah that is slower than building a single package localy, but hey gotta take what's given, right?

PS: Feel free to hit me up if you're stuck in the process (I've been there and it sucked). I'm also going to write a little blog post to adress this subject soon - please add further insights to #31908

@s-gbz Thanks! I'll try your solution today.

I'm trying to understand how the angular team actually develops the framework. Do they just write the tests before the feature and test once it all passes?

Oh, @edusperoni, thanks for clarifying. I wish I knew the answer - I'm still learning. :)

I would also like to see some more information about how to debugg tests, but also an improved PR submission checklist, because on each push for #36897, I've discovered something new that I need to check: a new command or a new requirement.

cc @aikidave (docs team lead) fyi

This is good information! I'll talk with folks and see how we can provide better information for you!

What is the ETA on this? Is there any other online resource about running angular local fork? I am currently unable to test my changes, therefore unable to raise pull requests and contribute to angular.

I'm afraid I don't have an ETA to share as yet. The documentation team is working through our backlog as best we can! Thanks for your patience.

The "Running Tests Locally" section of docs/DEVELOPER.md doesn't seem to be enough to run all tests locally and the AIO pipelines fail if you make certain changes and you don't run those tests.

See #37389 (comment) and #37389 (comment)