chore(*): clean up package.json and CircleCI config

This is a follow-up to #16915, cleaning up `package.json` and
`.circleci/config.yml` and making release scripts executable.

.circleci/config.yml

@@ -1,4 +1,4 @@
-# Configuration file for https://circleci.com/gh/angular/angular
+# Configuration file for https://circleci.com/gh/angular/angular.js
 
 # Note: YAML anchors allow an object to be re-used, reducing duplication.
 # The ampersand declares an alias for an object, then later the `<<: *name`
@@ -12,55 +12,29 @@
 # https://circleci.com/docs/2.0/reusing-config/#getting-started-with-config-reuse
 version: 2.1
 
-# Workspace initially persisted by the `setup` job, and then enhanced by `build-npm-packages` and
-# `build-ivy-npm-packages`.
+# Workspace persisted by the `setup` job to share build artifacts with other jobs.
 # https://circleci.com/docs/2.0/workflows/#using-workspaces-to-share-data-among-jobs
 # https://circleci.com/blog/deep-diving-into-circleci-workspaces/
 var_workspace_location: &workspace_location ~/
 
-# Filter to run a job on builds for pull requests only.
-var_only_on_pull_requests: &only_on_pull_requests
-  filters:
-    branches:
-      only:
-        - /pull\/\d+/
-
-# Filter to skip a job on builds for pull requests.
-var_skip_on_pull_requests: &skip_on_pull_requests
-  filters:
-    branches:
-      ignore:
-        - /pull\/\d+/
-
-# Filter to run a job on builds for the master branch only.
-var_only_on_master: &only_on_master
-  filters:
-    branches:
-      only:
-        - master
-
 # Executor Definitions
 # https://circleci.com/docs/2.0/reusing-config/#authoring-reusable-executors
 # **NOTE 1**: Pin to exact images using an ID (SHA). See https://circleci.com/docs/2.0/circleci-images/#using-a-docker-image-id-to-pin-an-image-to-a-fixed-version.
 #             (Using the tag in not necessary when pinning by ID, but include it anyway for documentation purposes.)
-# **NOTE 2**: If you change the version of the docker images, also change the `cache_key` suffix.
-# **NOTE 3**: If you change the version of the `*-browsers` docker image, make sure the
-#             `--versions.chrome` arg in `integration/bazel-schematics/test.sh` specifies a
-#             ChromeDriver version that is compatible with the Chrome version in the image.
 executors:
   default-executor:
     parameters:
       resource_class:
         type: string
         default: medium
     docker:
-      - image: circleci/node:12.16.3
+      - image: circleci/node:12.16.3@sha256:8fe514dae7585bbee1c64bf5a6cd4dcdf393316b5c87565b47e31014872c8860
     resource_class: << parameters.resource_class >>
     working_directory: ~/ng
   cloud-sdk:
     description: The docker container to use when running gcp-gcs commands
     docker:
-      - image: google/cloud-sdk:alpine
+      - image: google/cloud-sdk:alpine@sha256:7d0cae28cb282b76f2d9babe278c63c910d54f0cceca7a65fdf6806e2b43882e
 
 
 # Command Definitions
@@ -72,21 +46,7 @@ commands:
       - attach_workspace:
           at: *workspace_location
 
-  # Install shared libs used by Chrome.
-  install_chrome_libs:
-    description: Install shared Chrome libs
-    steps:
-      - run:
-          name: Install shared Chrome libs
-          command: |
-            sudo apt-get update
-            # Install GTK+ graphical user interface (libgtk-3-0), advanced linux sound architecture (libasound2)
-            # and network security service libraries (libnss3) & X11 Screen Saver extension library (libssx1)
-            # which are dependendies of chrome & needed for karma & protractor headless chrome tests.
-            # This is a very small install which takes around 7s in comparing to using the full
-            # circleci/node:x.x.x-browsers image.
-            sudo apt-get -y install libgtk-3-0 libasound2 libnss3 libxss1
-
+  # Java is needed for running the Closure Compiler (during the `minall` task).
   install_java:
     description: Install java
     steps:
@@ -210,8 +170,8 @@ jobs:
     steps:
       - custom_attach_workspace
       - init_environment
-      - run: yarn -s grunt ci-checks
-      - run: yarn commitplease "${CI_COMMIT_RANGE/.../..}"
+      - run: yarn grunt ci-checks
+      - run: yarn commitplease "$CI_COMMIT_RANGE"
       - run: yarn grunt validate-angular-files
 
   unit-test:

CONTRIBUTING.md

@@ -125,7 +125,7 @@ Before you submit your pull request consider the following guidelines:
 * Follow our [Coding Rules][developers.rules].
 * If the changes affect public APIs, change or add relevant [documentation][developers.documentation].
 * Run the AngularJS [unit][developers.tests-unit] and [E2E test][developers.tests-e2e] suites, and ensure that all tests
-  pass. It is generally sufficient to run the tests only on Chrome, as our continous integration test will
+  pass. It is generally sufficient to run the tests only on Chrome, as our continuous integration test will
   run the tests on additional browsers.
 * Run `yarn grunt eslint` to check that you have followed the automatically enforced coding rules
 * Commit your changes using a descriptive commit message that follows our
@@ -153,7 +153,7 @@ Before you submit your pull request consider the following guidelines:
 * In GitHub, send a pull request to `angular.js:master`. This will trigger the check of the
 [Contributor License Agreement](#cla) and the continuous integration tests.
 
-* If you find that the continous integration tests have failed, look into the logs to find out
+* If you find that the continuous integration tests have failed, look into the logs to find out
 if your changes caused test failures, the commit message was malformed etc. If you find that the
 tests failed or times out for unrelated reasons, you can ping a team member so that the build can be
 restarted.

DEVELOPERS.md

@@ -428,7 +428,7 @@ if it is enclosed in <pre>...</pre> tags and the code lines themselv
 It is possible to embed examples in the documentation along with appropriate e2e tests. These
 examples and scenarios will be converted to runnable code within the documentation.  So it is
 important that they work correctly.  To ensure this, all these e2e scenarios are run as part of the
-continous integration tests.
+continuous integration tests.
 
 If you are adding an example with an e2e test, you should [run the test locally](#e2e-tests) first
 to ensure it passes. You can change `it(...)` to `fit(...)` to run only your test,

package.json

@@ -35,6 +35,7 @@
     "dgeni-packages": "^0.26.5",
     "eslint-plugin-promise": "^3.6.0",
     "event-stream": "~3.1.0",
+    "firebase-tools": "^8.3.0",
     "glob": "^6.0.1",
     "google-code-prettify": "1.0.1",
     "grunt": "^1.0.1",
@@ -99,11 +100,7 @@
     "sorted-object": "^1.0.0",
     "stringmap": "^0.2.2"
   },
-  "dependencies": {
-    "firebase": "^7.14.4",
-    "firebase-tools": "^8.3.0",
-    "node-glob": "^1.2.0"
-  },
+  "dependencies": {},
   "resolutions": {
     "//1": "`[email protected]` does not work with Node.js 10.x on Windows 10",
     "//2": "(E.g. see https://github.com/gulpjs/gulp/issues/2162 and https://github.com/nodejs/node/issues/25132.)",