Documentation - Creating a 'secure' package. #24580
I'm submitting a...
Not an issue - sharing a process.
Minimal reproduction of the problem with instructions
What is the motivation / use case for changing the behavior?
@alxhub asked me to pop by and share.
Creating a 'Secure' Angular Library Package
I am an an enterprise architect who currently calls the arena of Fintech home. Years ago, we set out to modernize our main client facing systems and their supporting APIs. For the front end, we set our targets and AngularJS and didn't look back. Our challenge wasn't a small one - coming from a .Net and Java heavy world in terms of our existing code bases, part of our systems included a 3rd party ecosystem which allowed partner developers to extend our base functionality. Not only could partner developers extend the system's core functionality, but they could also package up their extensions in a manner compatible with our systems so that they could be resold to other organizations who also benefited from this new functionality.
The initial release of our revamped, albiet feature-limited system, was very well recieved - and almost immediately the ecosystem began to grown around it at a pace nearly exceeding our ability to continue to build out our initial system... A good problem to have - and so we continued to iterate and release.
Fast foward a year+ and several iterations later, we found ourselves with a functional codebase now ported to Angular 4. Angular 4 provided us some new and interesting challenges - namely that the ballgame, and its associated rules which we had build our system around had changed. While we had completely redesigned our extensibility approach, which is outside of the scope of this document, we were faced with the very real problem of the 3rd party developer flow, which had seemingly degraded from Angular 1.x to 4.x under our design.. While I can't go too far into the details, a lot of the 3rd party work had to be done out of band - integration testing with the core platform required round trips to the build server under our design just to get a working environment to test your enhancements (which may have been broken due to an errant keystroke that had gone unnoticed before pushing for the build - so you had to do it all over again).
This approach 'worked', but was never quite favored - it felt hacky and was difficult to maintain multiple builds...
Needless to say, we had to find a better way.
A Better Way
Enter Angular 6 - with it's fancy first class support of library generation. Not quite knowing what we were getting into, a port of our 4.x to 6.x was undertaken - and went surprisingly well. From here we worked to break out all of our implementation which was intended to be 'protected' in to Angular Libraries (with the help of the Angular CLI and ng-packagr). Once our cleanup efforts were complete, we had a handful of Angular 6 feature libraries and what is essentially a shell application to tie them together.
While I am still struggling to grok the hows and whys that this works, it seemingly just does for now. In Angular 4 Land, we could never quite get our obfuscated/minified package to work for AOT Prod builds, though it worked perfectly fine for JIT builds; hence our need for 2 pacakges. But I am happy to report that the rules are apparently different in Angular 6 Land - as we are now able to create this 'one package to rule them all' in a relatively straight forward manner.
During some of the exploratory phase, I'd spoken on gitter with Alex Rickabaugh (@alxhub) about what we were trying to accomplish. While our interactions were small in regards to our Angular 4 efforts, I popped back in to update Alex on the success we'd found with Angular 6 - at which time he requested that I do a quick writeup in the case that it might assist others....
...so here we are...
Here be dragons...
As previously mentioned, the steps are currently pretty straight forward. For the following overview, let's assume we arrived here from "ng g library awesomesauce".
Note: Again, here be dragons. I am not a web security expert. The process described here may or may not stand up to rigorous scrutiny. We're in the process of vetting this and working to clear the security requirements imposed upon us - but so far this appears to be fitting the bill for us, so perhaps it will for you too.
The text was updated successfully, but these errors were encountered:
Here's a tldr version:
Yes, agreed @jasonaden .
Currently we're automating this pre-packaging process via gulp tasks and associated npm scripts in our projects, but it would definitely be nice to have this get first class support in the CLI using flags and/or via package configs.
If we could get first class support in the CLI and the Angular Package Format, it would enable folks seeking to accomplish this to possibly speed up their production build time in that non-desired assets wouldn't have to actually be generated ( esm5, esm2015, esm5, and fesm2015 in our case, for example).
An additional sticking area for us in this exercise was that validation applied at build time varies a bit for application builds vs library builds. For example, the same codebase that builds as an application without error results in TS4023 (likely unavoidable), TS4033, TS2307 (likely unavoidable), additional validation checks seem to be in place for lib builds to ensure functional implementation matches template calls in regards to arguments, and TS0 warnings from tsickle resulting in build failure in ng-packagr due to invalid JSDoc markup...
That last one (TS0 warnings breaking the build) was our biggest one - lots of 'invalid JSdoc markup' in our codebase that wasn't a build error issue as an application, but that completely breaks the ability to build the library with ng-packagr (I believe I read this is due to additional strictness being required for closure compiler, where things will apparently break with some of these invalid types in JSDocs - though this may not be 100% accurate as it was just my take away from reading the various open issues on this matter in Angular CLI, ng-packagr, and tsickle).
Likely related to this request; a feature request for package support for assets, scripts and styles in the same way as is supported with application projects: angular/angular-cli#11317
Howdy again, folks.
While I'm sure this won't be the approach if this winds up evolving into CLI / APF as an enhancement, I created a minimal project to demonstrate the approach in the case that it assists: https://github.com/mattezell/SecureAngularLibrary
Let me know if there is any way that I can actually contribute to this :)