chore: create script for updating RELEASE.md before PR

[NeilAn99]

chore: create script for updating RELEASE.md before PR

Fixes #148

Description of changes:

• Added the prompt-sync and semver packages.
• Created a script pr-updater.js located in the packages directory that can be run using npm run release. This script will prompt the contributor for the package changed, the type of PR, and the description(s) of changes made. Then, the script will find the corresponding RELEASE.md file and update it.

For example, the running the script:

Will produce the following RELEASE.md:

Tag a reviewer: @ayoayco

Tasks:

• I have ran the build command to make sure apps are working: npm run build
• I have ran the tests to make sure nothing is broken: npm run test
• I have ran the linter to make sure code is clean: npm run lint
• I have reviewed my own code to remove changes that are not needed

[netlify]

✅ Deploy Preview for astro-reactive canceled.

Name	Link
🔨 Latest commit	f24841c
🔍 Latest deploy log	https://app.netlify.com/sites/astro-reactive/deploys/6394ee110dffab00087d5850

[netlify]

✅ Deploy Preview for astro-reactive-docs canceled.

Name	Link
🔨 Latest commit	f24841c
🔍 Latest deploy log	https://app.netlify.com/sites/astro-reactive-docs/deploys/6394ee119c71ed0008417377

[Icyscools]

I think it should check the input from the prompt before going to the next step. This should prevent someone accidentally (or intentionally) type an invalid option.

[ayoayco]

@NeilAn99 since the bump of version will not be needed per PR, you can remove adding the version for now in your script. Just focus on the change and type. Where the type could either be "fix" or "feature"

So no need to add the big text for version but just items like:

Features
- Feature description text

Fixes
- Change description text
- dix description 2

[Icyscools]

I prefer to use switch-case here since type value should be only '1', '2' and '3'. Also, this else here will let other value than '1' and '2' make a major change. 😅

[ayoayco]

As I mentioned above we can remove this versioning as we will only bump the version when releasing, and not per PR.

However I think we want to ask the contributors if the change will break the existing examples/demo apps and if they have also ipdated them.

After typing a code change description, we ask:
"Will this code change break existing examples and/or demo applications? Y/N"

Then we can just add a text (BREAKING CHANGE) beside the code change items

Features
- Change  description text (BREAKING CHANGE)
...

[ayoayco]

Thanks @NeilAn99, this is great progress for the project. We want to get this in! Can you go through a couple of suggestions first?

[ayoayco]

Oh and one very important thing I missed: the package.json "version" property in the package needs to be updated to the same as the version that is written to the RELEASE.md.

Please ignore this comment ☝️ and focus on the first comments. Bumping versions will only be done on release, and not per PR, so I will work on this after your pr is merged @NeilAn99

[NeilAn99]

I have updated the code so that it doesn't deal with versioning, added some input checking and focused on features/fixes. Now running the script will look like:

and will produce:

Multiple updates to the same package will look like:

Is this acceptable? @Icyscools @ayoayco

[Icyscools]

LGTM! 🚀 However, please fix a conflict on a package.json. I think it was a line in the publish script. Make sure to use it from our latest main branch and it'll be safe to merge. 🦺

[NeilAn99]

I have resolved the conflict.

[ayoayco]

Thanks @Icyscools and @NeilAn99 -- I'm merging this now! :)