Let's use the debug module instead of console.log to output debug info.

We might add Github OAuth for safe user authorization (and webhook creation for repos selected by him). Do we need it at this moment?

Main functionality feature of our application should be maintainers notification through comments (user mention) on non-collaborator pull requests. For that purpose, at first, we need authenticate our comment-bot on Github.

My suggestions:

• Authentication by personal access token set via .env variables;
• New bot account?

For now, useful content delivers to user via server-side rendering. I propose to split into client side logic (fetch data and render) and server-side REST-service.

Proposed improvements

• Use webpack for bundling client-side .js/.css/etc (and injecting .js to .html via HtmlWebpackPlugin)
• Use fetch on client-side for requesting data from server;
• From server side, process data and return as JSON;

1. Use the debug module in client scripts.
2. Add the unhandledrejection and error event handlers to the window object.

Notes:

• Ideally, we should inform the server if something goes wrong on the client.
• I will give you 1000 ⭐️ if you manage to separate the client error handling script from the other scripts and be able to inform the server about syntax errors in your client scripts.

Try to implement transpiling in #16 and enable the strict typechecking via the strict: true in another PR.

Currently, mock-data is retrieved manually and for tests we are using two services: one for actual App and another for mock github API endpoints.

Using Nock module can be quite useful:

• fixtures-fetching can be automated;
• no need for additional routing;
• no need for dedicated App which host mock third-party API.

Thus, I think that using this module should lead to simplicity of code.

As mentioned in the pull request #30, our template system on the client is far from perfect and can certainly be improved.

We can move our page to a dedicate directory (e.g. resources/html) and use app.static to allow Express optimizing requests to it.

Currently, our code is limited to start just one server. To make our code reusable, we should create and export an App class, that allows creating multiple instances of our app on different ports.

Take a look at the dotenv module to get server's host and port from environment variables and .env files.

Let's add TypeScript to our project and use import/export instead of require/module.exports.

I don't insist that you should transform all your JS files to TS files right now. Just try setting allowJS: true & checkJs: false and compile your JS files without type checking.

Some other hints about the initial configuration:
esModuleInterop: true
target: es2018

Note: we can use TypeScript for client scripts too, and enable the built-in SystemJS bundling.

We should be able to update user statuses on the fly. Let's do it via polling as the first attempt. We can introduce a config option (e.g. POLLING_INTERVAL) and constantly query our API. We also have to write a functional (e2e) test to cover this functionality.

For now, Express instance incapsulated in our App class and we don't have any way to configure settings.

Let's build a prototype that will be given via .env files or env variables:

• a repo slug (organization name + / + repo name)
• a list of comma-separated GitHub nicknames of repo maintainers
  should display:
• a list of Pull Requests created by non-maintainers in the given repository

No fancy UI is required, you can use regular HTML tables to display the data.

For dynamic created stuff (fetched PRs, etc) we need some kind of template engine.

Currently, the npm start cannot start our app. We should fix it.

Hint: take a look at the process.mainModule and this paragraph about modules :)

• Allow gathering PRs from a list of repositories
• Add a text area and a submit button to allow batch commenting to selected PRs
• Add checkboxes to PR descriptions to allow comment selectively.