@angular-wave/angular.ts 0.0.1

package/RELEASE.md

@@ -0,0 +1,98 @@
+# AngularJS Release instructions
+
+
+## Compare the list of commits between stable and unstable
+
+There is a script - compare-master-to-stable.js - that helps with this.
+We just want to make sure that good commits (low risk fixes + docs fixes) got cherry-picked into stable branch and nothing interesting got merged only into stable branch.
+
+
+## Pick a release name (for this version)
+
+A super-heroic power (adverb-verb phrase).
+
+
+## Generate release notes
+
+Example Commit: https://github.com/angular/angular.js/commit/7ab5098c14ee4f195dbfe2681e402fe2dfeacd78
+
+1) Run
+
+```bash
+node_modules/.bin/changez -o changes.md -v <new version> <base branch>
+```
+
+2) Review the generated file and manually fix typos, group and reorder stuff if needed.
+3) Move the content into CHANGELOG.md add release code-names to headers.
+4) Push the changes to your private github repo and review.
+5) cherry-pick the release notes commit to the appropriate branches.
+
+
+## Pick a commit to release (for this version)
+
+Usually this will be the commit containing the release notes, but it may also be in the past.
+
+
+## Run "release" script
+
+  ```bash
+  scripts/release/release.sh --git-push-dryrun=false --commit-sha=8822a4f --version-number=1.7.6 --version-name=gravity-manipulation
+  ```
+
+  1) The SHA is of the commit to release (could be in the past).
+
+  2) The version number and code-name that should be released, not the next version number (e.g. to release 1.2.12 you enter 1.2.12 as release version and the code-name that was picked for 1.2.12, cauliflower-eradication).
+
+  3) You will need to have write access to all the AngularJS github dist repositories and publish rights for the AngularJS packages on npm.
+
+
+## Update GitHub milestones
+
+1) Create the next milestone if it doesn't exist yet-giving ita due date.
+2) Move all open issues and PRs for the current milestone to the next milestone<br>
+  You can do this by filtering the current milestone, selecting via checklist, and moving to the next milestone within the GH issues page.
+
+3) Close the current milestone click the milestones tab and close from there.
+4) Create a new holding milestone for the release after next-but don't give it a due date otherwise that will mess up the dashboard.
+
+
+## Push build artifacts to CDN
+
+Google CDNs are fed with data from google3 every day at 11:15am PT it takes only few minutes for the import to propagate).
+If we want to make our files available, we need submit our CLs before this time on the day of the release.
+
+
+## Don't update the package.json (branchVersion) until the CDN has updated
+
+This is the version used to compute what version to link to in the CDN. If you update this too early then the CDN lookup fails and you end up with 'null, for the version, which breaks the docs.
+
+
+## Verify angularjs.org download modal has latest version (updates via CI job)
+
+The versions in the modal are updated (based on the versions available on CDN) as part of the CI deploy stage.
+(You may need to explicitly trigger the CI job. e.g. re-running the last `deploy` job.)
+
+
+## Announce the release (via official Google accounts)
+
+Double check that angularjs.org is up to date with the new release version before sharing.
+
+1) Collect a list of contributors
+
+use: `git log --format='%aN' v1.2.12..v1.2.13 | sort -u`
+
+2) Write a blog post (for minor releases, not patch releases) and publish it with the "release" tag
+3) Post on twitter as yourself (tweet from your heart; there is no template for this), retweet as @AngularJS
+
+
+## Party!
+
+
+## Major Release Tasks
+
+1) Update angularjs.org to use the latest branch.
+2) Write up a migration document.
+3) Create a new git branch for the version that has been released (e.g. 1.8.x).
+4) Check that the build and release scripts still work.
+5) Update the dist-tag of the old branch, see https://github.com/angular/angular.js/pull/12722.
+6) Write a blog post.

package/SECURITY.md

@@ -0,0 +1,16 @@
+# Security Policy
+
+## Supported Versions
+
+**AngularJS support has officially ended as of January 2022.**
+[See what ending support means](https://docs.angularjs.org/misc/version-support-status)
+and [read the end of life announcement](https://goo.gle/angularjs-end-of-life).
+
+Visit [angular.io](https://angular.io) for the actively supported Angular.
+
+| Version     | Supported          | Status                | Comments                             |
+| ----------- | ------------------ | --------------------- | ------------------------------------ |
+| 1.8.x       | :x:                | All support ended     |                                      |
+| 1.3.x-1.7.x | :x:                | All support ended     |                                      |
+| 1.2.x       | :x:                | All support ended     | Last version to provide IE 8 support |
+| <1.2.0      | :x:                | All support ended     |                                      |

package/TRIAGING.md

@@ -0,0 +1,135 @@
+# Triage new issues/PRs on github
+
+This document shows the steps the AngularJS team is using to triage issues.
+The labels are used later on for [planning releases](#assigning-work).
+
+
+## Automatic processing
+
+We have tools (e.g. [Mary Poppins]) that automatically add comments and labels to issues and PRs.
+The following is done automatically so you don't have to worry about it:
+
+* Label `cla: yes` or `cla: no` for pull requests
+* Label `GH: *`
+    * `PR` - issue is a PR
+    * `issue` - otherwise
+
+
+## Triaging Process
+
+This process based on the idea of minimizing user pain
+[from this blog post](http://www.lostgarden.com/2008/05/improving-bug-triage-with-user-pain.html).
+
+1. Open the list of [non triaged issues](https://github.com/angular/angular.js/issues?q=is%3Aopen+sort%3Acreated-desc+no%3Amilestone)
+    * Sort by submit date, with the newest issues first
+    * You don't have to do issues in order; feel free to pick and choose issues as you please.
+    * You can triage older issues as well
+    * Triage to your heart's content
+1. Assign yourself: Pick an issue that is not assigned to anyone and assign it to you
+1. Understandable? - verify if the description of the request is clear.
+    * If not, [close it][] according to the instructions below and go to the last step.
+1. Duplicate?
+    * If you've seen this issue before [close it][], and go to the last step.
+    * Check if there are comments that link to a dupe. If so verify that this is indeed a dupe, [close it][], and go to the last step.
+1. Bugs:
+    * Label `Type: Bug`
+    * Reproducible? - Steps to reproduce the bug are clear. If they are not, ask for a clarification. If there's no reply after a week, [close it][].
+    * Reproducible on master? - <http://code.angularjs.org/snapshot/>
+1. Non bugs:
+    * Label `Type: Feature`, `Type: Chore`, or `Type: Perf`
+    * Belongs in core? – Often new features should be implemented as a third-party module rather than an addition to the core.
+      If this doesn't belong, [close it][], and go to the last step.
+    * Label `needs: breaking change` - if needed
+    * Label `needs: public api` - if the issue requires introduction of a new public API
+1. Label `browser: *` - if the issue **only** affects a certain browser
+1. Label `frequency: *` – How often does this issue come up? How many developers does this affect? Chose just one of the following:
+    * low - obscure issue affecting a handful of developers
+    * moderate - impacts a common usage pattern
+    * high - impacts most or all AngularJS apps
+1. Label `severity: *` - How bad is the issue? Chose just one of the following:
+    * security issue
+    * regression
+    * memory leak
+    * broken expected use - it's hard or impossible for a developer using AngularJS to accomplish something that AngularJS should be able to do
+    * confusing - unexpected or inconsistent behavior; hard-to-debug
+    * inconvenience - causes ugly/boilerplate code in apps
+1. Label `component: *`
+    * In rare cases, it's ok to have multiple components.
+1. Label `PRs plz!` - These issues are good targets for PRs from the open source community. In addition to applying this label, you must:
+    * Leave a comment explaining the problem and solution so someone can easily finish it.
+    * Assign the issue to yourself.
+    * Give feedback on PRs addressing this issue.
+    * You are responsible for mentoring contributors helping with this issue.
+1. Label `origin: google` for issues from Google
+1. Assign a milestone:
+   * Backlog - triaged fixes and features, should be the default choice
+   * Current 1.x.y milestone (e.g. 1.3.0-beta-2) - regressions and urgent bugs only
+
+
+1. Unassign yourself from the issue
+
+
+## Tips
+
+* Label `resolution: *`
+    * these tags can be used for labeling a closed issue/PR with a reason why it was closed.
+    * Right now there are only a few rejection reasons, but we can add more as needed. Feel free to suggest one to a core team member. We don't use this label for issues that were fixed or PRs that were merged.
+
+
+## Closing an Issue or PR
+
+We're grateful to anyone who takes the time to submit an issue, even if we ultimately decide not to act on it.
+Be kind and respectful as you close issues. Be sure to follow the [code of conduct][].
+
+1. Always thank the person who submitted it.
+1. If it's a duplicate, link to the older or more descriptive issue that supersedes the one you are closing.
+1. Let them know if there's some way for them to follow-up.
+    * When the issue is unclear or reproducible, note that you'll reopen it if they can clarify or provide a better example. Mention [plunker] or [fiddle] for examples. Watch your notifications and follow-up if they do provide clarification. :)
+    * If appropriate, suggest implementing a feature as a third-party module.
+
+If in doubt, ask a core team member what to do.
+[Brian](https://github.com/btford) is probably the person to ask.
+You can mention him in the relevant thread like this: `@btford`.
+
+**Example:**
+
+> Thanks for submitting this issue!
+> Unfortunately, we don't think this functionality belongs in core.
+> The good news is that you could easily implement this as a third-party module and publish it to the npm registry.
+
+
+## Assigning Work
+
+These criteria are then used to calculate a "user pain" score.
+Work is assigned weekly to core team members starting with the highest pain, descending down to the lowest.
+
+```
+pain = severity × frequency
+```
+
+**severity:**
+
+- security issue (6)
+- regression (5)
+- memory leak (4)
+- broken expected use (3)
+- confusing (2)
+- inconvenience (1)
+
+**frequency:**
+
+- low (1)
+- moderate (2)
+- high (3)
+
+**Note:** Security issues, regressions, and memory leaks should almost always be set to `frequency: high`.
+
+
+[![Analytics](https://ga-beacon.appspot.com/UA-8594346-11/angular.js/TRIAGING.md?pixel)](https://github.com/igrigorik/ga-beacon)
+
+
+[close it]: #closing-an-issue-or-pr
+[code of conduct]: https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md
+[Mary Poppins]: https://github.com/btford/mary-poppins
+[plunker]: http://plnkr.co/
+[fiddle]: http://jsfiddle.net/

package/css/angular.css

@@ -0,0 +1,22 @@
+@charset "UTF-8";
+
+[ng\:cloak],
+[ng-cloak],
+[data-ng-cloak],
+[ng-cloak],
+.ng-cloak,
+.ng-hide:not(.ng-hide-animate) {
+  display: none !important;
+}
+
+ng\:form {
+  display: block;
+}
+
+.ng-animate-shim {
+  visibility:hidden;
+}
+
+.ng-anchor {
+  position:absolute;
+}