denysvitali/thebestmotherfuckingwebsite

1. This repository is a static website project, not a traditional app with a backend. The whole architecture centers on generating a deployable dist/ site from source assets under src/, then serving that output through static hosting infrastructure.

2. The content/layout layer is Pug-based. src/pug/index.pug is the page template source, which is compiled into HTML during the build. This is the main structural boundary for the site’s markup.

3. The presentation layer is authored in Less via src/less/main.less. That stylesheet is compiled and bundled into the final site assets, separating style authoring from the deployed CSS.

4. Client-side behavior lives in TypeScript/JavaScript. src/index.ts is the TypeScript entrypoint, and src/js/main.fucking.js suggests there is also existing JavaScript logic or legacy script content. These are bundled for browser execution rather than run on a server.

5. Static assets are kept alongside the source, including images in src/img and the web manifest in src/dist/site.webmanifest. That indicates the site includes browser-facing metadata and asset delivery as part of the compiled output.

6. The build pipeline is webpack-driven. webpack.config.js and webpack.config.prod.js define how templates, styles, scripts, and assets are transformed into deployable files. tsconfig.json confirms TypeScript compilation is part of that pipeline.

7. The repository appears to keep some distributable files in version control under src/dist/, including LICENSE.txt and a js/ bundle. That suggests the project may ship prebuilt static assets alongside source, or preserve generated files that are part of the site’s final payload.

8. Deployment is purely static-file based. The README says to run yarn run build and deploy the contents of dist/, so the runtime artifact is just a directory of HTML/CSS/JS/assets rather than a service with APIs or databases.

9. There is explicit web-server configuration for nginx under nginx/. The main config plus snippets for CORS, gzip, and security headers show the site is intended to be served by a static web server with production-grade HTTP settings, not by application middleware.

10. Docker support is included via Dockerfile, so the site can be packaged into a container that serves the built static files. This is a deployment boundary only; it does not introduce application logic.

11. CI/CD is present through .github/workflows/deploy.yml and .travis.yml. That implies automated build-and-deploy flow from source to static hosting, likely with publishing of the generated dist/ artifact.

12. CNAME indicates the site is tied to a custom domain, reinforcing that the final architecture is “build static site → publish to hosting/CDN/nginx → serve globally.” The project’s main data flow is one-way: authored source in src/ becomes compiled assets in dist/, which are then served to browsers.