Refactor

.gitignore

@@ -6,3 +6,5 @@ npm-debug.log
 .DS_Store
 *.iml
 **/.serverless
+dist/
+.nyc_output/

.travis.yml

@@ -11,5 +11,6 @@ deploy:
   provider: npm
   email: $NPM_EMAIL
   api_key: $NPM_KEY
+  before_deploy: "npm run build"
   on:
     branch: master

CHANGELOG.md

@@ -6,6 +6,17 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 ## [Unreleased]
 
+## [3.0.0] - 2019-01-24
+
+### Changed
+- Refactored from Javascript into Typescript
+- Created BasePathMapping through API rather than through CloudFormation
+
+### Removed
+- Support for migrating CNAMEs to A Alias Records
+  - In 1.0, we only created CNAME records. In 2.0 we deprecated CNAME creation and started creating A Alias records and migrated CNAME records to A Alias records. Now in 3.0, we only create A Alias records.
+
+
 ## [2.6.13] - 2019-01-25
 
 ### Added

DomainInfo.ts

@@ -0,0 +1,26 @@
+/**
+ * Wrapper class for Custom Domain information
+ */
+class DomainInfo {
+
+    public domainName: string;
+    public hostedZoneId: string;
+
+    /**
+     * Sometimes, the getDomainName call doesn't return either a distributionHostedZoneId or a regionalHostedZoneId.
+     * AFAICT, this only happens with edge-optimized endpoints.
+     * The hostedZoneId for these endpoints is always the one below.
+     * Docs: https://docs.aws.amazon.com/general/latest/gr/rande.html#apigateway_region
+     * PR: https://github.com/amplify-education/serverless-domain-manager/pull/171
+     */
+    private defaultHostedZoneId: string = "Z2FDTNDATAQYW2";
+
+    constructor(data: any) {
+        this.domainName = data.distributionDomainName || data.regionalDomainName;
+        this.hostedZoneId = data.distributionHostedZoneId ||
+            data.regionalHostedZoneId ||
+            this.defaultHostedZoneId;
+    }
+}
+
+export = DomainInfo;

README.md

@@ -31,8 +31,9 @@ apigateway:POST                     /domainnames/*/basepathmappings
 cloudfront:UpdateDistribution       *
 route53:ListHostedZones             *
 route53:ChangeResourceRecordSets    hostedzone/{HostedZoneId}
-route53:GetHostedZone               hostedzone/{HostedZoneId}
-route53:ListResourceRecordSets      hostedzone/{HostedZoneId}
+route53:GetHostedZone               *
+route53:ListResourceRecordSets      *
+iam:CreateServiceLinkedRole         arn:aws:iam::${AWS::AccountId}: role/aws-service-role/ops.apigateway.amazonaws.com/AWSServiceRoleForAPIGateway
 ```
 ### CloudFormation
 Alternatively you can generate an least privileged IAM Managed Policy for deployment with this:
@@ -97,15 +98,17 @@ To remove the created custom domain:
 serverless delete_domain
 ```
 # How it works
-Creating the custom domain takes advantage of Amazon's Certificate Manager to assign a certificate to the given domain name. Based on already created certificate names, the plugin will search for the certificate that resembles the custom domain's name the most and assign the ARN to that domain name. The plugin then creates the proper A Alias records for the domain through Route 53. Once the domain name is set it takes up to 40 minutes before it is initialized. After the certificate is initialized, `sls deploy` will create the base path mapping and assign the lambda to the custom domain name through CloudFront.
+Creating the custom domain takes advantage of Amazon's Certificate Manager to assign a certificate to the given domain name. Based on already created certificate names, the plugin will search for the certificate that resembles the custom domain's name the most and assign the ARN to that domain name. The plugin then creates the proper A Alias records for the domain through Route 53. Once the domain name is set it takes up to 40 minutes before it is initialized. After the certificate is initialized, `sls deploy` will create the base path mapping and assign the lambda to the custom domain name through CloudFront. All resources are created independent of CloudFormation.
+
+Note: In 1.0, we only created CNAME records. In 2.0 we deprecated CNAME creation and started creating A Alias records and migrated CNAME records to A Alias records. Now in 3.0, we only create A Alias records.
 
 ## Running Tests
 To run unit tests:
 ```
 npm test
 ```
 
-To run integration tests, set an environment variable `TEST_DOMAIN` to the domain you will be testing for (i.e. `example.com` if creating a domain for `api.example.com`). Then, 
+To run integration tests, set an environment variable `TEST_DOMAIN` to the domain you will be testing for (i.e. `example.com` if creating a domain for `api.example.com`). Then,
 ```
 export TEST_DOMAIN=example.com
 npm run integration-test
@@ -126,7 +129,6 @@ Unit tests are found in `test/unit-tests`. Integration tests are found in `test/
 * (5/23/2017) CloudFormation does not support changing the base path from empty to something or vice a versa. You must run `sls remove` to remove the base path mapping.
 * (1/17/2018) The `create_domain` command provided by this plugin does not currently update an existing Custom Domain's configuration. Instead, it only supports updating the Route 53 record pointing to the Custom Domain. For example, one must delete and recreate a Custom Domain to migrate it from regional to edge or vice versa, or to modify the certificate.
 * (8/22/2018) Creating a custom domain creates a CloudFront Distribution behind the scenes for fronting your API Gateway. This CloudFront Distribution is managed by AWS and cannot be viewed/managed by you. This is not a bug, but a quirk of how the Custom Domain feature works in API Gateway.
-* (12/19/2018) Recreating a custom domain after deleting it does not work if the basePathMapping is not set. The workaround is to always run `sls remove` when running `sls delete_domain`.
 
 # Responsible Disclosure
 If you have any security issue to report, contact project maintainers privately.