fix(chat-service): remove dead runtime path-alias registration crashing prod boot - #201
Merged
Merged
Conversation
…ng prod boot
dist/main.js crashed on every boot with "ReferenceError: __dirname is not
defined in ES module scope" — chat-service's package.json has
"type": "module", and __dirname does not exist in ES modules.
registerTsConfigPaths({ baseUrl: __dirname, ... }) was added when this
service briefly built with tsgo alone and needed runtime path-alias
resolution (chat-service commit 4e3ce3a). Once tsc-alias was added back
to chat-service's build script (matching every other service), it started
rewriting @app/* @common/* etc. to real relative ./app/*.js imports at
build time, making the runtime registration in main.ts fully redundant —
and it was never removed, so it kept running __dirname unconditionally on
every boot regardless of runtime module format.
Confirmed via a fresh build: dist/main.js contains zero @app/@common/
@infrastructure/@modules bare specifiers (tsc-alias already resolved them
all to relative paths) and zero __dirname references. Booted dist/main.js
directly: it now proceeds through NestJS module resolution and DI all the
way to AppConfig.validate(), failing only on missing env vars in this
isolated worktree (expected — no .env here), where it previously crashed
before a single import even resolved.
Also removes the now-unused tsconfig-paths runtime dependency.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
dist/main.jscrashed on every single boot withReferenceError: __dirname is not defined in ES module scope— chat-service'spackage.jsonhas"type": "module", and__dirnamedoes not exist in ES modules.registerTsConfigPaths({ baseUrl: __dirname, ... })inmain.tswas added when this service briefly built withtsgoalone (commit4e3ce3abc) and needed runtime path-alias resolution. Oncetsc-aliaswas added back to chat-service's build script (matching every other service), it started rewriting@app/*/@common/*/etc. to real relative./app/*.jsimports at build time — making the runtime registration fully redundant. It was never removed, so it kept unconditionally referencing__dirnameon every boot.registerTsConfigPathsblock and itstsconfig-pathsimport/dependency. No other service has this pattern (confirmed by repo-wide grep) and no other file in chat-service depends on it.Release notes
chat-service is broken in production right now — every container crashes immediately on boot. This restores it to booting correctly.
Remaining work
None. This is a minimal, targeted fix — two files changed, nothing else touched.
Test plan
npx tsgo --noEmit— cleannpm run lint— 0 errors (71 pre-existing warnings, unrelated to this change)npm run test— 1616/1616 tests passing (2 suites hit a pre-existing Windows/Jest path-resolution flake unrelated to this change — verified the flaky files pass 26/26 in isolation)npm run build— confirmeddist/main.jscontains zero__dirnamereferences and zero bare@app//@common//@infrastructure//@modules/specifiers (tsc-aliasalready resolves all of them to relative.jsimports)dist/main.jsdirectly: it now proceeds through NestJS module resolution and DI all the way toAppConfig.validate(), failing only on missing env vars in this isolated worktree (expected — no.envhere). Previously it crashed before a single import even resolved.