refactor: migrate to ES modules

Author: marcossevilla

.github/ISSUE_TEMPLATE/config.yml

@@ -1 +1 @@
-blank_issues_enabled: false
+blank_issues_enabled: false

CONTRIBUTING.md

@@ -7,7 +7,7 @@ git checkout main
 git pull
 ```
 
-2. Run the script that will generate the CHANGELOG for you: 
+2. Run the script that will generate the CHANGELOG for you:
 
 ```bash
 sh tool/release_ready.sh <new-version>
@@ -19,26 +19,27 @@ sh tool/release_ready.sh <new-version>
 
 The release_ready script will:
 
- - Create a new branch just for this release and checkout to it.
- - Automatically update the CHANGELOG file with the associated changes.
+- Create a new branch just for this release and checkout to it.
+- Automatically update the CHANGELOG file with the associated changes.
 
-3. Manually remove the *(deps-dev)* scope or other entries of the conventional commits entries in the CHANGELOG
-4. Add the changes and commit with the commit message that the *release_ready* script outputted.
-5. Raise a Pull Request, the title should be the same as the commit message outputted by the *release_ready* script.
+3. Manually remove the _(deps-dev)_ scope or other entries of the conventional commits entries in the CHANGELOG
+4. Add the changes and commit with the commit message that the _release_ready_ script outputted.
+5. Raise a Pull Request, the title should be the same as the commit message outputted by the _release_ready_ script.
 6. When the Pull Request is merged, tag a new release to the commit. When adding the tag ensure:
-    - The tag is pointing to the commit that you recently merged.
-    - The title of the tag should be v<new-version>
-    - The title of the release should be v<new-version>
-    - The description should be a raw copy of the CHANGELOG’s file version’s body you recently crafted (without the version header). If in doubt, see the other released tags as an example.
+   - The tag is pointing to the commit that you recently merged.
+   - The title of the tag should be v<new-version>
+   - The title of the release should be v<new-version>
+   - The description should be a raw copy of the CHANGELOG’s file version’s body you recently crafted (without the version header). If in doubt, see the other released tags as an example.
 7. After the release is tagged the new changes will be available by the the following syntax:
 
 ```yaml
 VeryGoodOpenSource/..@v<new-version>
 ```
 
-Where: 
+Where:
 
 - `<new-version>`: The version of this new workflow or action, for example: 0.2.1
+
 8. Go to the **main** branch and ensure it is up to date with the remote:
 
 ```yaml
@@ -54,12 +55,11 @@ For the Workflow or Action to be updated for those users using the `@<major-vers
 sh tool/retag_v<major-version>.sh <new-version>
 ```
 
-Where: 
+Where:
 
 - `<major-version>`: Is the major version of the release, for example in 2.16.3 the major version is 2. For more information see the [semantic versioning documentation](https://semver.org/).
 - `<new-version>`: The version of this new workflow or action, for example: 0.2.1.
 
-
 If your change is a breaking change and requires a new major release you should update the name of the retag script and its `v<major-version>` instances.
 
 10. After the retag the new changes will be available by the the following syntax: