fix: add main.single-spa.ts to compilation and exclude polyfills-es5 from Webpack entries

[arturovt]

Hey @joeldenning

This PR provides fixes for 3 issues:

• it updates tsconfig.app.json.files to contain path to main.single-spa.ts
• it excludes polyfills-es5 from Webpack entries to fix Terser error
• destroys bootstrapped module after calling flush() and removes DOM nodes if Ivy is enabled

I have updated Angular to 9 version in the current project, it required to update runSchematic to runSchematicAsync since it's deprecated, that's what I did in the index.spec.ts file.

Actually I wanted to kill 2 birds with one stone :D
But there is a problem with builders (browser and dev-server in src/builders). It cannot be built since most of the functionality is not exported anymore @angular-devkit/build-angular (it contained breaking changes in Angular 8).

IMHO those builders have to be removed from the current project because they can still remain in older npm versions. What do you think?

Closes #128 #130 #148

I tested these changes on my application and it works like a charm.

[joeldenning]

Thanks for your awesome work here. This is really helpful and will push things forward a lot with single-spa-angular + Angular 9.

IMHO those builders have to be removed from the current project because they can still remain in older npm versions. What do you think?

In the past, I have been quite hesitant about creating separate versions of single-spa-angular to support different versions of Angular 9. The every-six-months pace of Angular breaking changes, combined with how hard it is to provide single-spa-angular support for each version, scares me that we'd have to have a branch and single-spa-angular major for every Angular version.

A sob story

I hope you'll forgive me for the sob story below 😄

The single-spa-angular project doesn't really have good open source maintainers working on it, which exacerbates that concern. I am the main one who maintains it, but I don't know Angular that well and don't even enjoy using it. The single-spa core team is in a similar boat, although with even less Angular experience. I honestly don't think we'd have the open source labor hours or desire that would be necessary to support a separate version of single-spa-angular for most major versions of Angular.

You can see the effects of this maintenance problem by checking the issue queues for single-spa-angular versus any other single-spa related repo - we have several showstopping bugs (#113, #94) and a ton of small bugs that we haven't addressed for months or even years. Additionally, Angular projects using single-spa-angular have massive bundle sizes in comparison to their "just Angular" counterparts. Also, support for CSS and other Angular assets is sketchy at best, as described here.

Since I usually pride myself on staying on top of the issue queues and providing quality open source software to users, I've even considered archiving single-spa-angular and shutting down Angular support altogether, since single-spa-angular's quality is substantially lower than any other open source software I've ever built.

I spent >50 hours last year on reviving single-spa-angular and obtaining Angular 8 support, and it was not enjoyable. Even after all that work, single-spa-angular produces bundles that are irresponsibly large, doesn't support CSS or Angular assets, and has showstopping bugs. I spent >10 hours writing the documentation for single-spa-angular, and still it's incomplete and I get dozens of questions a week from users that are completely lost.

My work supporting other frameworks (react, Vue, Svelte, angularjs, preact, etc) was extremely easy in comparison. My conclusion is that Angular's architecture is specifically and unavoidably contrary to single-spa's vision of microfrontends (Angular has a hard assumption that each project has html file with assets), and its code is both complex and buggy (especially angular router, which probably still doesn't properly unmount 4 years after its release, how Angular doesn't even allow multiple instances of itself on the same page due to ZoneJS, even though that's explicitly what ZoneJS was made for).

I share all this not to cause uncertainty for you and others about this project, but rather to share how we are in desperate need for someone to step up and help out with this project.

Proposal

I just invited you as a collaborator to single-spa-angular with write access, as an attempt to revive the project. I will be happy to review PRs and respond in issue queues as I can, but would love to have someone who actually knows Angular and is invested in it to push the project forward.

If that's interesting to you, I'd be happy to defer to you on what's best for the project, including the creation of separate branches/majors for Angular majors.

[joeldenning]

Why is single-spa removed as a dependency?

[arturovt]

It is in two places - dependencies and devDependencies. I accidentally removed it from dependencies, but actually have to remove from devDepedencies. I will revert.

[arturovt]

@joeldenning I have accepted your invitation.

I understand everything that you've said regarding Angular, maintenance, issues and other things. I used single-spa-angular in production year ago thus I'm sure that this project has ambitions. Every project requires maintenance, new features, bug fixing, it is an integral part 😄 I'm interested in supporting this project under your guidance (PR reviews, comments, etc.), that will be super appreciated!

[joeldenning]

I'm interested in supporting this project under your guidance

👍 awesome!

But there is a problem with builders (browser and dev-server in src/builders). It cannot be built since most of the functionality is not exported anymore @angular-devkit/build-angular (it contained breaking changes in Angular 8).

Shall we proceed with this being a new major version of single-spa-angular, then? single-spa-angular@4? If so, could you delete the old builders, and then I'll create a 3.x branch for maintenance of single-spa-angular@3.

[arturovt]

Sure. I can remove builders completely in a separate PR.