Makefile is a nice standardized interface for working with project-related scripts.

The makefile should not require a global installation of anything, unless mentioned explicitly in prerequisites

Also: self-contained help is a protip -> in this way you don't have to update README every time you change the Makefile targets

Note: update prerequisites in README and guides

This will ensure that the code is consistent across the codebase, I'd recommend eslint + some sensible present + tweaks to make it work in our case ;)

There is a need for a second person who can dedicate his/her attention & time to this project.

Suggestion: a tiny banner on the website + info in README maybe? :)

Can we have an issue for this?

Originally posted by @allgreed in #34

Yes, we can.

This issue also applies to creating the agencyType array.

Changing stuff on frontend and backend while using caches in various places doesn't play along well. Users are reporting broken links due to old, cached versions of frontend trying to communicate with new backend, which is cached only for short period of time.

There is need to introduce some way for old frontend to purge when new version is detected.

Could you please put expected values inline with test examples?

Originally posted by @allgreed in #34

Please add LICENSE so that people can contribute freely knowing on which license their work will be published.

I personally recommend (in order of preference for this project):

• Some GPL flavour (in order to go full Stallman :D)
• WTFPL (confuses the hell out of those corporate lawyers xD)
• MIT (industry standard)

This shouldn't be too much work, since there are only 2 machines + Cloudflare afaik ;)

Might pay off in the future. Treat as low priority.

This will allow contributions to happen. Find a few areas where it would be easy for a person unfamiliar with the codebase to improve something. For every good-first-issue closed consider adding a new one.

Tests are code too, and they should uphold our marvellous code standards!

Tip:

• see SOURCES variable inside Makefile ;)

They aren't any good if they just sit around ;)

++ red-black deployment are a good idea

Also: please do it via a script. This way you can rerun the script as many times as you want instead of having to remember the commands

Given that this is almost a pure function, this should be fairly easy to test.

Tips:

• extract this function into src/utilities.js
• extract new Date() call into a default parameter -> this should simplify testing
• list sample inputs and expected outputs of the function -> then write a test
• use jest-each to reduce the boilerplate

Perhaps pull the latest service worker from here:
https://github.com/OneSignal/OneSignal-Website-SDK/releases
and self host:
https://github.com/OneSignal/OneSignal-Website-SDK/wiki/Self-Hosting-the-JavaScript-Web-SDK

Pros:

• service worker not blocked by ad-blockers
• finer control over the content of sw

Cons

• adds complexity

When a person links to r.w on social media, the backend should provide proper metadata and render a preview of the data linked. For example preview of the name of the launch, date, time and description on links on Facebook, Google Search, Twitter and others.

Some sections of legacy code are commented out - they are either not working properly or not needed anymore.

Review them and do what needs to be done about them!

There is a single global .gitignore in the repo, please split this gitignore into component level ignores (backend / frontend)

Currently due to folder structure all tests have to have require(../../the/real/path). See if the preamble (the dots) can be removed. See jest configuration options regarding imports.

Humans shouldn't have to do this ;)

Because why not? :D

Add an easy way of writing, running and getting reports from unit tests.

Note: Probably jest is a good idea.

Size of card is not the same for each element. While the content needs more lines it is heigher than other card elements.

'agencies shortname' array should probably be wrapped in a function and tested

Those basic E2Es are fine at this level - we should just make them work ;)

We're either going monolith + fronted or different services - there's no middle ground

Pro monolith:

• we're a small team
• it's almost always simpler

Pro services:

• those components already live as separate processes
• they have different life-cycles
• they can fail independently

Docker allows for portability and is a great way to manage artifacts