Source maps · Manual

What it is for

JavaScript in production ships minified. The stack that arrives from the browser says main-a1b2.js:1:48210, and that is nowhere: you cannot search it, you cannot group by it properly, and you cannot fix it.

The source map is the file your bundler already generates, and it translates that position back to src/pedido/salvar.ts:120. Uploading it here makes meulog translate on the way in.

How to upload

Through the screen, or through the API in your build pipeline, alongside the deploy. What identifies a map is project plus version: meulog uses the map for the version the error happened on, not the most recent one.

Why this matters more than it looks

The translation happens before meulog computes the fingerprint. Without a source map, the same bug in two different builds becomes two groups, because the minified file name changes on every build. With it, it is one error.

The native equivalent: symbol maps

A compiled executable has the same problem in a different shape: the stack comes out as ErpClient.exe+0x0004A1B0, which counts volume and does nothing else. The map your linker writes translates that address back to uVendas.pas:412, and it is uploaded to /api/v1/symbols with the server token, at the end of the build.

meulog reads two map formats today, and it works out which is which by looking at the file — there is nothing to pick on upload:

Delphi map: segments, publics by value and the line numbers of each unit. Full translation, file and line.
MSVC map (link.exe /MAP, also C++Builder): the address comes from the Rva+Base column. Line numbers only if the build passed /MAPINFO:LINES; without them you still get the method name.

A third format is a file in app/plugins/symbols/ and no change anywhere else. A map nobody recognises is refused on upload, saying so — the usual cause is sending the .exe instead of the .map.

The third case: the build that renames

R8 — which Flutter turns on by default for an Android release build — does not minify position or trade a line for an address: it renames. com.acme.Pedido.gravar becomes a.b.c.d, and the frame arrives like that, with Unknown Source where the file should be.

Why that is worse than unreadable

Two builds rename differently. Without undoing the renaming before the fingerprint is computed, the same bug becomes a new group on every version — and the errors screen starts counting releases instead of problems.

The mapping.txt the build writes goes up at /api/v1/mappings with the server token, one per project and version:

curl -sf -X POST "$MEULOG/<account>/api/v1/mappings" \
  -H "Authorization: Bearer $MEULOG_SERVER_TOKEN" \
  -F "version=$VERSION" \
  -F "map=@app/build/outputs/mapping/release/mapping.txt"

The reader is ProGuard / R8 mapping, and it recognises itself from the file too — there is nothing to pick when sending. A new rename format is a file in app/plugins/renamer/ and nothing else. The common mistake here is sending the .aab instead of the mapping.txt, and the refusal says so.

When you do not need it

If your project is Ruby, Python or anything that neither goes through a bundler nor compiles to a native executable, neither of these screens is for you. They only serve code that reaches production transformed.

What you should see

The list of maps by version, with the upload date. After uploading, stacks for that version start coming out with real file names.