How to contribute? | sls-mentor

How to contribute ? A step by step tutorial

Create a new rule

Clone the github repository

git clone git@github.com:sls-mentor/sls-mentor.git

https://github.com/sls-mentor/sls-mentor

In your CLI, go to the core folder

cd sls-mentor/packages/core

It will automaticaly create the new files needed for your rule according to the following tree structure:

It will update the index.ts files to correctly export the new files. And it will create 3 new files :

doc.md with the documentation of the rule

index.ts with the actual code of the rule

test.ts with the end-to-end test for the rule

Write the code of your rule

Configuration	Source code
Find a name and an error message for your rule Set the categories and the AWS service related to it Fix a level for the rule, it should reflect the importance and the effort it takes to be solved. (You can ask for help from the sls-mentor team to find the right level)	Fetch the configuration of the ressources concerned by the rule Check the configuration of the ressources (you might need to read the sdk documentation to find the right method to do so) Return an array composed of the ressources with their ARN and if they verify the rule

Write the documentation of your rule in the "doc.md" file

The documentation of your rule will be displayed on the website.
Document your rule for others to understand why it's important and how to fix it. Additionnaly you can add links to ressources to help the user understand the rule.

(Optional) Write the end to end test of your rule in the "test.ts" file

First of all, you should test that your rule works as expected on your stack.
Then you can write an end to end test that will check that your rule works on a specially crafted stack. The passing and failing created ressources will be tagged so they can be easily checked. ( You might need to create a new default construct for your specific resource.)
⚠️ Some rules should not be tested:

If testing the rule requires provisioning a non-serverless resource (for example a RDS or a Lambda with provisioned concurrency) don’t test it. We care about the planet (and our costs 🤡). We don’t want to allocate compute or storage units only for our test stack.
CloudFormation does not support tags on some resources: SES resources like ConfigurationSet and Identity for example. As you need to tag the created resource to be able to check if the rule works, rules that concern these types of resources cannot be tested.

In these cases, you can remove the test file.

Finally, you can open a pull-request 🌟

Create a branch with your new rule and open a pull-request with the main branch. The sls-mentor maintainer team will review it and publish it in the next version.

If your rule needs resources from a service that is not supported:

Create your own ARN class

Create a new ARN class extending CustomARN (copy LambdaFunctionARN for example)
Adapt the logic of this class to be able to be generated from a CloudFormation resourceId, and from any information returned by the AWS SDK (example: fromFunctionName for Lambdas)
Add a case to the big switch case in fetchCloudFormationResourceArns. This will allow sls-mentor to turn resources from CloudFormation into your new ARN class.
Add a client for your resource in clients folder. This way we only use one client to send the requests to AWS.
Create a folder yourResource with a list<YourResource>.ts file in the listResources folder
In this file, use the AWS SDK to list all the needed resources from the user's account (don't forget pagination), and then use your new ARN class methods to turn the sdk data into your new ARN class
Invoke this function in the listAllResources