chore(migrate): migrate from react to next (#30)

Author: darkterminal

.eslintrc.json

@@ -0,0 +1,7 @@
+{
+	"extends": ["next/core-web-vitals", "next", "prettier"],
+	"rules": {
+		"react/no-unescaped-entities": "off",
+		"react/no-children-prop": "off"
+	}
+}

.github/workflows/release.yml

@@ -0,0 +1,16 @@
+name: Semantic Release
+
+on:
+  workflow_dispatch:
+
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - name: Install Dependencies
+        run: yarn install
+      - name: Semantic Release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: npx semantic-release

.gitignore

@@ -1,28 +1,32 @@
-# Logs
-logs
-*.log
+# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
+
+# dependencies
+/node_modules
+/.pnp
+.pnp.js
+
+# testing
+/coverage
+
+# next.js
+/.next/
+/out/
+
+# production
+/build
+
+# misc
+.DS_Store
+*.pem
+
+# debug
 npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
-pnpm-debug.log*
-lerna-debug.log*
-
-node_modules
-dist
-build
-dist-ssr
-*.local
-
-# Editor directories and files
-.vscode/*
-!.vscode/extensions.json
-.idea
-.DS_Store
-*.suo
-*.ntvs*
-*.njsproj
-*.sln
-*.sw?
-
-.env
-.env.*
+.pnpm-debug.log*
+
+# local env files
+.env*.local
+
+# vercel
+.vercel

.gitpod.yml

@@ -3,3 +3,7 @@ out/
 dist/
 test-fixtures/
 node_modules/
+.next/
+.github/
+package-lock.json
+public/collections/stories/

.npmrc

@@ -1,5 +1,6 @@
 {
-  "tabWidth": 2,
-  "useTabs": false,
-  "printWidth": 90
+	"singleQuote": true,
+	"tabWidth": 2,
+	"semi": true,
+	"useTabs": true
 }

.prettierignore

@@ -0,0 +1,19 @@
+# OUR SOLID CODE OF CONDUCT
+
+Yo, welcome to the Street Community Programmer! We believe in creating an inclusive and respectful community where everyone feels comfortable and heard. To make sure we're all on the same page, we have a few guidelines we ask everyone to follow. Check it out:
+
+# The Code
+1. Respect each other.
+2. Keep it clean.
+3. Be yourself.
+4. Stay open-minded.
+
+## The Consequences
+If you violate any of these guidelines, we may take action, including but not limited to:
+- Removing your contributions from the community
+- Blocking you from the community
+- Not inviting you to our next party (just kidding, we'll still invite you)
+
+## The Callout
+If you witness someone violating the code of conduct, please let us know. You can reach out to any of our moderators or shoot us an email at [missing-email](meh).
+

.prettierrc

@@ -0,0 +1,35 @@
+# THE CULTURE AND GUIDELINES
+
+Hey there, fellow Metaphor creators! We're stoked that you want to join our team of Punks, Freestylers, and Software Freestyle Engineers. Let's rock this joint with some awesome contributions!
+
+## How to join the fun
+1. First off, fork the repository to your own account, champ.
+2. Clone that repo to your local machine like a boss.
+3. Now create a new branch, name it something cool.
+4. Start making those changes and commit them to your branch like a pro ([with this mantra](CONVENTIONAL_COMMIT.md)).
+5. Push your branch to your forked repository and let the magic happen.
+6. Create a pull request from your branch to the main repository.
+7. Sit tight and wait for our team to give you the thumbs up or give you some sweet feedback.
+8. Once you get the green light, your changes will be merged into the main repository. Congratulations, you're a Metaphor master now!
+
+## How you can contribute
+
+Don't matter if you're an expert or just starting out, we welcome all kinds of contributions. Here are some ideas to get you started:
+
+- Create some fresh code snippets or metaphors that will blow our minds!
+- Jazz up existing code snippets or metaphors with your own unique flair.
+- Join our community forums and discussions, and get involved in the fun.
+- Help us make our documentation and resources even better.
+- Share your skills and expertise with our community and show us what you've got!
+
+## Guidelines for contributions
+
+To keep our community cool and funky, please stick to these guidelines when you're making contributions:
+
+- Respect your fellow Metaphor creators and be kind to each other.
+- Follow our code of conduct at all times, we don't want no trouble here.
+- Only submit your original creations, don't steal other people's stuff.
+- Make sure your contributions fit in with our community values of creativity, diversity, and innovation.
+- Stay focused and relevant to our mission of using code to make the world a better place.
+
+Thanks for your interest in contributing to Metaphore (SCP)! We can't wait to see your sick skills and mind-blowing contributions. Let's do this!

CODE_OF_CONDUCT.md

@@ -0,0 +1,62 @@
+# Conventional Commits
+
+Conventional Commits is a specification for adding human and machine-readable meaning to commit messages. It provides a consistent way to structure commit messages, making them more informative and easier to understand. By following the Conventional Commits specification, it becomes easier to automate changelog generation, versioning, and releases.
+
+## Format
+
+A Conventional Commit message consists of a header, an optional body, and an optional footer. The header has a special format that includes a type, a scope, and a subject. The body provides additional information about the change, and the footer provides a place to add metadata about the commit, such as issue tracking numbers.
+
+The format of a header is as follows:
+
+```bash
+<type>[optional scope]: <subject>
+```
+
+### Type
+
+The type field is required and describes the kind of change that the commit introduces. Examples of types include:
+
+- feat: a new feature
+- fix: a bug fix
+- docs: documentation changes
+- style: changes that do not affect the meaning of the code, such as formatting
+- refactor: code changes that neither fix a bug nor add a feature
+- test: adding missing tests or correcting existing tests
+- chore: changes to the build process or auxiliary tools
+
+### Scope
+
+The scope field is optional and describes the part of the codebase that is affected by the change.
+
+### Subject
+
+The subject field is required and provides a brief summary of the change.
+
+**Examples**
+
+Here are some examples of Conventional Commit messages:
+
+```bash
+feat(users): add user registration endpoint
+```
+
+```bash
+fix(authentication): handle invalid credentials error
+```
+
+```bash
+docs(readme): add example usage
+```
+
+**Benefits**
+
+Using Conventional Commits provides a number of benefits:
+
+- Provides a consistent way to structure commit messages across a team or organization
+- Makes it easier to generate changelogs, versioning, and releases
+- Provides more information about changes, making it easier to understand the purpose of a commit
+- Makes it easier to automate processes such as generating release notes or updating documentation
+
+**Conclusion**
+
+By using Conventional Commits, you can make your commits more informative and easier to understand, helping your team and organization work more efficiently.