Files
remark42/site/content/docs/contributing/frontend/index.md
T
Dmitry VerkhoturovandGitHub fb7b6c2cdd Serve the build-independent web assets from the backend (#2181)
* Serve the build-independent web assets from the backend

`privacy.html`, `markdown-help.html` and the `400x400.jpeg` it embeds carry
no template variable, link no script or stylesheet, and are imported by
nothing in the widget. They now live in `backend/app/webassets/assets`,
embedded there, and are served under `/web` alongside the frontend build.

`/web` reads the frontend build first and falls back to them, which is what
lets an operator replace one by dropping a file into `--web-root`. That is
what `privacy.html` needs: it describes remark42.com, while the
authorization guide tells operators to hand its URL to Google and Facebook
as their own application's privacy policy.

Only a missing file falls through. An unreadable file in the web root keeps
reporting as unreadable rather than being silently replaced by the embedded
copy, and a name the filesystem rejects reports as missing rather than as a
server error, both matching what `http.Dir` did.

The dev server serves the same directory, so the Markdown help link in the
comment form resolves on the dev port as well as in production.

The two pages are served as they are written. `markdown-help.html` was
minified before, and its formatted inline stylesheet is most of its 8.5 kB;
that is 2.4 kB more over the wire, behind the hour-long cache header the
file server already sets.

Drops `copy-webpack-plugin`, which had no other pattern, and the stylelint
entries that only ever matched these files.

* Make pnpm dev:app start again

The dev server has been failing to start on two counts, so the flow the
contributing guide documents does not run at all.

`webpack-cli` 4 drives `webpack-dev-server` 5 through the argument order
of an older major, handing it the compiler where it expects the options
object. It rejects that against its schema and exits, complaining about an
unknown `_assetEmittingPreviousFiles` property, which is a field of the
compiler. `webpack-cli` 7 is the release that declares
`webpack-dev-server` 5 as a peer.

Past that, `http-proxy-middleware` resolves to 4.1.1, which no longer
accepts the two-argument call `webpack-dev-server` makes, so the `/api`
and `/auth` proxies throw on startup. It is pulled in by the security
override for CVE-2025-32996, the only override in the file with no upper
bound: `>=2.0.10` matches every later major. Bounding it to the 2.x line
keeps the fix and the API `webpack-dev-server` calls.

With both in place `pnpm dev:app` serves the widget and the pages under
`/web` on port 9000.
2026-08-21 18:43:06 -05:00

8.1 KiB
Raw Blame History

title
title
Frontend Development Guidelines

Prerequisites

Frontend for Remark42 is built with Preact and Redux.

{{< note "💡" >}} We highly recommend checking out Preact documentation. React libraries are not usable here: the store bindings and the i18n helpers are small local modules under app/. {{< /note >}}

In order to inject Remark42 widgets into websites we use iframe and postMessage for communication between a site and the widget. Simple widgets like counter widget can be injected as a script because it doesn't have its own interface.

While developing, we set up environment which imitates real world example. We serve the page which uses Remark42 config and inject all the widgets on it. You can check it on our demo site. After successful installation you should have the same page running locally.

Installation

You must have at least 2GB RAM or swap enabled for building.

  • install Node.js 20 or higher (we recommend using NVM for node version autoswitch)
  • install PNPM 10
  • run pnpm i inside ./frontend

Running pnpm i will set up pre-commit hooks into your git repository. They are used to reformat your frontend code using prettier and lint with eslint and stylelint before every commit.

{{< note "🚨" >}} Please use 127.0.0.1 and not localhost to access the server; otherwise, CORS will prevent your browser from authentication to work correctly. You could alter the address for dev auth with the REMARK_URL environment variable. {{< /note >}}

Development

Run frontend with remote backend

You can run frontend against demo instance of Remark42. This method of running Remark42 frontend code is preferred when you make a translation or visual adjustments that are easy to see without extensive testing. For this method we use our demo instance of Remark42 served on https://demo.remark42.com

For local development mode with Hot Reloading, use pnpm dev:app. In this case, webpack will serve files using webpack-dev-server on 127.0.0.1:9000. By visiting http://127.0.0.1:9000/web/, you will get a page with the main comments' widget communicating with a demo server backend running on https://demo.remark42.com. But you will not be able to log in with any OAuth providers due to security reasons.

You can attach the frontend to the locally running backend from frontend/apps/remark42 folder and providing the REMARK_URL environment variable.

npx cross-env REMARK_URL=http://127.0.0.1:8080 pnpm dev:custom

{{< note "ℹ️" >}} If you want to redefine env variables such as PORT on your local instance, you can add the .env file to the ./frontend folder and rewrite variables as you wish. For such functional, we use dotenv. {{< /note >}}

Run frontend with backend locally

This option of running Remark42 frontend code is preferred when you need extensive testing of your code changes, as you'll have your backend and configure it as you want, for example, enable any auth and notifications method you need to test. You can use that set up to develop and test both frontend and backend.

To bring the backend up, run:

cp compose-dev-frontend.yml compose-private.yml
# now, edit / debug `compose-private.yml` to your heart's content

# build and run
docker compose -f compose-private.yml up --build

Then in the new terminal tab or window, run the following to start the frontend with Hot Reloading:

cd frontend
pnpm dev:app

Developer build running by webpack-dev-server supports devtools for React and Redux.

It starts Remark42 backend on 127.0.0.1:8080 and adds local OAuth2 provider "Dev". To access the frontend running by Node, go to http://127.0.0.1:9000/web/. By default, you would be logged in as dev_user, defined as admin. You can tweak any of the supported parameters in corresponded yml file.

Manual testing after changes

Frontend Docker Compose config (compose-dev-frontend.yml) by default skips running backend related tests.

{{< note "🚨" >}} Before submitting your changes as a Pull Request, run the backend using the docker compose -f compose-dev-frontend.yml build --build-arg SKIP_FRONTEND_BUILD=""; docker compose -f compose-private.yml up command and test your changes against http://127.0.0.1:8080/web/, frontend, built statically (unlike frontend on port 9000, which runs dynamically). That is how Remark42 authors will test your changes once you submit them. {{< /note >}}

Static build

Remark42 frontend can be built statically, and that's how the production version works: frontend is built and then resulting files embedded into the backend, which serves them as-is. Node is not running when a user starts Remark42, only the backend written in Go programming language, which also serves pre-built frontend HTML and JS and CSS files.

Run pnpm build inside ./frontend, and result files will be saved in ./frontend/apps/remark42/public.

/web is served from two sources. This build output comes first; anything it does not emit is served from backend/app/webassets/assets, embedded in the backend binary, which is where privacy.html, markdown-help.html and 400x400.jpeg live. A plain page or image the bundler does not process belongs there rather than here. Those files sit outside the frontend toolchain, so prettier, stylelint and pnpm lint do not see them.

Code Style

  • The project uses TypeScript to analyze code statically
  • The project uses Eslint and Stylelint to check the frontend code. You can manually run via pnpm lint
  • Git Hooks (via husky) installed automatically on pnpm i. They check and try to fix code style if possible, otherwise commit will be rejected
  • If you want IDE integration, you need Eslint and Stylelint plugins to be installed. Also, you have configured Eslint for work in subdirectory. For example, you have to add configuration for VSCode like that "eslint.workingDirectories": ["frontend/apps/remark42"]

CSS Styles

  • Now we are migrating to CSS Modules, which is a recommended way of stylization. A file with styles should be named like component.module.css
  • Old component styles use BEM notation (at least it should): block__element_modifier. Also, there are mix classes: block_modifier
  • The new way to name CSS selectors is camel-case like blockElemenModifier and use clsx to combine it
  • Component base style resides in the component's root directory with a name of component converted to kebab-case. For example, ListComments style is located in ./app/components/list-comments/list-component.tsx
  • Any other files should also be named in kebab-case. For example, ./app/utils/get-param.ts

Imports

  • Imports for TypeScript, JavaScript files should be without extension: ./index, not ./index.ts
  • If the file resides in the same directory or subdirectory, the import should be relative: ./types/something
  • Otherwise, it should be imported by absolute path relative to src folder like common/store which mapped to ./app/common/store.ts in webpack, tsconfig, and Jest

Testing

  • Project uses Jest as test framework
  • Testing Library is used for UI tests
  • Jest checks files that match regex \.(test|spec)\.ts(x?)$, i.e., comment.test.tsx, comment.spec.ts
  • Tests are running on push attempt
  • Example tests can be found in ./app/components/auth/auth.spec.tsx, ./app/store/user/reducers.test.ts

Notes

Frontend part being bundled on docker env gets placed on /src/web and is available via http://{host}/web. For example, embed.mjs entry point will be available at http://{host}/web/embed.mjs

Learn More