feat(init): initial commit

Author: bassrock

.github/CODEOWNERS

@@ -0,0 +1,2 @@
+#All Files/PRS
+*                         @pocket/backend

.github/workflows/linter.yml

@@ -0,0 +1,95 @@
+---
+###########################
+###########################
+## Linter GitHub Actions ##
+###########################
+###########################
+name: Lint Code Base
+
+#
+# Documentation:
+# https://help.github.com/en/articles/workflow-syntax-for-github-actions
+#
+
+#############################
+# Start the job on all pull requests #
+#############################
+on:
+  # Run on every pull request created or updated
+  # https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#pull_request
+  pull_request:
+
+###############
+# Set the Job #
+###############
+jobs:
+  build:
+    # Name the Job
+    name: Lint Code Base
+    # Set the agent to run on
+    runs-on: ubuntu-latest
+
+    ##################
+    # Load all steps #
+    ##################
+    steps:
+      ##########################
+      # Checkout the code base #
+      ##########################
+      - name: Checkout Code
+        uses: actions/checkout@v2
+
+      ##########################
+      # Github Super Linter needs
+      # the latest definitions installed
+      ##########################
+      - name: Use Node.js 16.x
+        uses: actions/setup-node@v3
+        with:
+          node-version: 16.x
+      # Install our eslint packages.
+      # We may have custom tsconfigs, eslints that are brought in via a package.
+      - run: npm install
+
+      ################################
+      # Run Linter against code base #
+      ################################
+      - name: Lint Code Base
+
+        # We use the Github super linter, it can be cranky at times, so in that moment here are the docs https://github.com/github/super-linter
+        uses: docker://ghcr.io/github/super-linter:slim-v4
+
+        # All Environment variables are defined here https://github.com/github/super-linter#environment-variables
+        env:
+          # The name of the repository default branch.
+          DEFAULT_BRANCH: main
+
+          # Directory for all linter configuration rules.
+          # This is the root of our codebase.
+          LINTER_RULES_PATH: /
+
+          # Will parse the entire repository and find all files to validate across all types.
+          # NOTE: When set to false, only new or edited files will be parsed for validation.
+          VALIDATE_ALL_CODEBASE: true
+
+          # Filename for ESLint configuration (ex: .eslintrc.yml, .eslintrc.json)
+          TYPESCRIPT_ES_CONFIG_FILE: .eslintrc.js
+
+          #####
+          # Note: All the VALIDATE[LANGUAGE] variables behave in a specific way.
+          # If none of them are passed, then they all default to true.
+          # However if any one of the variables are set, we default to leaving any unset variable to false.
+          # This means that if you run the linter “out of the box”, all languages will be checked.
+          # But if you wish to select specific linters, we give you full control to choose which linters are run, and won’t run anything unexpected.
+          ####
+
+          # Flag to enable or disable the linting process of the JavaScript language. (Utilizing: eslint)
+          # Will validate any raw *.js in the repo like a jest.config.js
+          VALIDATE_JAVASCRIPT_ES: true
+
+          # Flag to enable or disable the linting process of the TypeScript language. (Utilizing: eslint)
+          VALIDATE_TYPESCRIPT_ES: true
+
+          # Flag to enable or disable the linting process of the YAML language.
+          # Note - disabled as of 26 Jan, 2022
+          # VALIDATE_YAML: true

.github/workflows/publish.yml

@@ -0,0 +1,35 @@
+name: Node.js Package
+
+on:
+  pull_request:
+    branches:
+      - main
+  push:
+    branches:
+      - main
+
+jobs:
+  validator:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: RoadieHQ/backstage-entity-validator@v0.3.2
+        with:
+          path: 'catalog-info.yaml'
+
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v2.4.1
+        with:
+          node-version: '16.x'
+          registry-url: 'https://registry.npmjs.org'
+          scope: '@pocket-tools'
+      - run: npm ci
+      - name: Semantic Release
+        uses: cycjimmy/semantic-release-action@v2
+        env:
+          GITHUB_TOKEN: ${{ secrets.CI_GITHUB_TOKEN }}
+          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
+          NODE_AUTH_TOKEN: ${{secrets.NPM_TOKEN}}

.gitignore

@@ -0,0 +1,12 @@
+.idea
+
+# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
+
+# dependencies
+/node_modules
+
+
+# misc
+.DS_Store
+
+npm-debug.log*

.nvmrc

@@ -0,0 +1 @@
+16

CODE_OF_CONDUCT.md

@@ -0,0 +1,8 @@
+# Community Participation Guidelines
+
+This repository is governed by Mozilla's code of conduct and etiquette guidelines.
+For more details, please read the
+[Mozilla Community Participation Guidelines](https://www.mozilla.org/about/governance/policies/participation/).
+
+## How to Report
+For more information on how to report violations of the Community Participation Guidelines, please read our '[How to Report](https://www.mozilla.org/about/governance/policies/participation/reporting/)' page.

CONTRIBUTING.md

@@ -0,0 +1,71 @@
+## Contributing
+
+Thank you for checking out our Pocket TSConfig work. We welcome contributions from everyone! By participating in this project, you agree to abide by the Mozilla [Community Participation Guidelines](https://www.mozilla.org/about/governance/policies/participation/).
+
+### Asking questions / receiving updates
+
+* Slack channel (Mozilla staff only): #team-backend
+
+* File issues/questions on Github: [https://github.com/Pocket/tsconfig/issues](https://github.com/Pocket/tsconfig/issues). We typically triage new issues every Monday.
+
+### Finding Bugs & Filing Tickets
+
+If you've found a bug, or have a feature idea that you you'd like to see, follow these simple guidelines:
+
+* Pick a thoughtful and concise title for the issue (ie. *not* Thing Doesn't Work!)
+
+* If you can reproduce the bug, give a step-by-step recipe
+
+* Include stack traces from the console(s) where appropriate
+
+* Screenshots and screen recordings welcome!
+
+* When in doubt, take a look at some existing issues and emulate
+
+### Contributing Code
+
+If you are new to the repo, you might want to pay close attention to these tags, as they are typically a great way to get started: Good First Bug, Bug, Chore, and Polish. If you see a bug that is not yet assigned to anyone, start a conversation with an engineer in the ticket itself, expressing your interest in taking the bug. If you take the bug, someone will set the ticket to Assigned to Contributor, so we can be proactive about helping you succeed in fixing the bug.
+
+When you have some code written, you can open up a Pull Request, get your code reviewed, and see your code merged into the codebase.
+
+### Creating Pull Requests
+
+You have identified the bug, written code and now want to get it into the main repo using a [Pull Request](https://help.github.com/articles/about-pull-requests/).
+
+All code is added using a pull request against the main branch of our repo. Before submitting a PR, please go through this checklist:
+
+* Fill out the pull request template as outlined
+
+* Make sure your PR will merge gracefully with the main branch at the time you create the PR, and that your commit history is 'clean'
+
+### Understanding Code Reviews
+
+You have created a PR and submitted it to the repo, and now are waiting patiently for you code review feedback. One of the projects module owners will be along and will either:
+
+* Make suggestions for some improvements
+
+* Give you a thumbs up in the comments section, indicating the review is done and the code can be merged
+
+Typically, you will iterate on the PR, making changes and pushing your changes to new commits on the PR. When the reviewer is satisfied that your code is good-to-go, you will get the coveted R+ comment, and your code can be merged. If you have commit permission, you can go ahead and merge the code to master, otherwise, it will be done for you.
+
+Our project prides itself on its respectful, patient and positive attitude when it comes to reviewing contributors' code, and as such, we expect contributors to be respectful, patient and positive in their communications as well.
+
+### Writing Good Git Commit Messages
+
+We like this overview by Chris Beams on "[How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)".
+
+The tl;dr is:
+
+1. [Separate subject from body with a blank line](https://chris.beams.io/posts/git-commit/#separate)
+
+2. [Limit the subject line to 50 characters](https://chris.beams.io/posts/git-commit/#limit-50)
+
+3. [Capitalize the subject line](https://chris.beams.io/posts/git-commit/#capitalize)
+
+4. [Do not end the subject line with a period](https://chris.beams.io/posts/git-commit/#end)
+
+5. [Use a verb to start your subject line (Add, Remove, Fix, Update, Rework, Polish, etc.)](https://chris.beams.io/posts/git-commit/#imperative)
+
+6. [Wrap the body at 72 characters](https://chris.beams.io/posts/git-commit/#wrap-72)
+
+7. [Use the body to explain *what* and *why* vs. *how*](https://chris.beams.io/posts/git-commit/#why-not-how)