Run unit tests from ng-packagr command

If integrated into ng-packagr, it will be in an opinionated way. It will look like this:

The tool chain will be plain-old Angular testing: karma, webpack, jasmine, istanbul

• myfoo.ts
• myfoo.spec.ts (right next to the comp, service, whatever being tested)
• **/*.spec.ts will be excluded from build task
• an auto-generated run-tests.js will include all spec files
  • var testContext = require.context(${opt.src}, true, /\.spec\.ts/);
• karma.conf.js will be auto-generated
• webpack.test.js will be auto-generated
• test runs will report: lcovonly, json, html (all written to disk). coverage report (html and json written to disk). coverage report to stdout (for the infamous gitlab stuff, still needs to be discussed, since GitLab users could simply pick up the json files and print to stdout with istanbul-combine)

[about-code]

Congratulations @dherges. I tried ng-packagr yesterday and its an excellent tool and absolutely easy to set up. It did exactly what I expected it to do. I am very happy to read (e.g. in #65) that you are focused and don’t plan to make it the next best swiss-army-knife-cli. I really appreciate and share such mindset. 👍

After having read this thread, though, and that you’d be willing to introduce support for unit testing and cli-like commands I asked myself if I would expect that from the tool. Spec files aren’t part of the distributed bundles and thus could actually be completely ignored by a packager/bundler. From that reasoning I came to conclude that I would probably consider anything which has to do with those files out of scope. I admit this might be kind of a fundamentalistic point of view and who am I to judge the plans for your project. I just thought to give you some feedback and start a discussion.

Part of why I am a little skeptic is, I am afraid that once this feature is implemented I need to pull in all these thousands of transitive dependencies of karma, webpack, jasmine etc. in order to enjoy ng-packagr. I am really interested to learn about your rationale and what your plans for ng-packagr are. Have you thought of implementing unit test support kind of like a separate ng-packagr-testing-plugin which is opt-in for anyone who has demand for a testing utility?

Thanks anyway. ❤️

[github-actions[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

_{This action has been performed automatically by a bot.}