Error on typescript compiling
stuartses
TRIALOP

a year ago

I've got this error when the command "npm run build" is used.
This is working fine locally and docker locally as well

this is my dockerfile:

# syntax=docker/dockerfile:1

ARG NODE_VERSION=18.16.0-alpine

FROM node:${NODE_VERSION}

WORKDIR /app

COPY package*.json ./

RUN ls -la /app

RUN npm install

COPY . .

RUN ls -la /app

RUN npm run build

ENV NODE_ENV=production
ENV DATABASE_URL="mongodb://mongo...."

EXPOSE 3000

CMD ["npm", "start"]

a section of my package.json

 "devDependencies": {
    "@eslint/js": "^9.18.0",
    "@types/express": "^5.0.0",
    "@types/jest": "^29.5.14",
    "@types/mongoose": "^5.11.97",
    "@types/node": "^22.10.6",
    "@typescript-eslint/eslint-plugin": "^8.20.0",
    "@typescript-eslint/parser": "^8.20.0",
    "eslint": "^9.18.0",
    "eslint-config-prettier": "^10.0.1",
    "eslint-plugin-prettier": "^5.2.2",
    "globals": "^15.14.0",
    "jest": "^29.7.0",
    "nodemon": "^3.1.9",
    "prettier": "^3.4.2",
    "ts-jest": "^29.2.5",
    "ts-node": "^10.9.2",
    "typescript": "^5.7.3",
    "typescript-eslint": "^8.20.0"
  },
  "dependencies": {
    "dotenv": "^16.4.7",
    "express": "^4.21.2",
    "mongoose": "^8.9.5"
  }

and a section of my package-lock

"packages": {
    "": {
      "name": "inventory-management",
      "version": "1.0.0",
      "license": "ISC",
      "dependencies": {
        "dotenv": "^16.4.7",
        "express": "^4.21.2",
        "mongoose": "^8.9.5"
      },
      "devDependencies": {
        "@eslint/js": "^9.18.0",
        "@types/express": "^5.0.0",
        "@types/jest": "^29.5.14",
        "@types/mongoose": "^5.11.97",
        "@types/node": "^22.10.6",
        "@typescript-eslint/eslint-plugin": "^8.20.0",
        "@typescript-eslint/parser": "^8.20.0",
        "eslint": "^9.18.0",
        "eslint-config-prettier": "^10.0.1",
        "eslint-plugin-prettier": "^5.2.2",
        "globals": "^15.14.0",
        "jest": "^29.7.0",
        "nodemon": "^3.1.9",
        "prettier": "^3.4.2",
        "ts-jest": "^29.2.5",
        "ts-node": "^10.9.2",
        "typescript": "^5.7.3",
        "typescript-eslint": "^8.20.0"
      }
    },

Have you ever have this kind of error?

View Deploy details

ⓘ Deployment information is only viewable by project members and Railway employees.

3 Replies

stuartses
TRIALOP

a year ago

this is part of the error log. There is not error locally

```
npx tsc

Jan 22 14:37:31

src/config.ts(1,1): error TS1127: Invalid character.

Jan 22 14:37:31

src/config.ts(1,2): error TS1127: Invalid character.

Jan 22 14:37:31

src/config.ts(1,3): error TS1127: Invalid character.
```

apolesskiy
FREE

8 months ago

Also encountering this issue. After creating a deployment from the terminal with railway up , the build fails with every character of every file printing a TS1127.

Deployment ID: 092b37ce-d63e-4124-8a4f-50d22f92b4ca

Example file: main.tsx (source file)

```
import { StrictMode } from 'react'

import { createRoot } from 'react-dom/client'

import './index.css'

import App from './App.tsx'

createRoot(document.getElementById('root')!).render(

<StrictMode>

<App />

</StrictMode>,

)
```

Error output for that file in the build log:

```
src/main.tsx(1,1): error TS1127: Invalid character.

src/main.tsx(1,2): error TS1127: Invalid character.

src/main.tsx(1,3): error TS1127: Invalid character.

...

src/main.tsx(1,228): error TS1127: Invalid character.

src/main.tsx(1,229): error TS1127: Invalid character.

src/main.tsx(1,230): error TS1127: Invalid character.
```

The total number of characters (230) matches the size of the input file, but tsc sees them as all on one line. I couldn't find an (easy) way to look inside the deployment artifact to check the files either with the CLI or through the web UI.

apolesskiy
FREE

8 months ago

Update: I added very aggressive .dockerignore and .railwayignore, which made the problem go away. I manged to get a regression by force-setting encoding (`ENV LANG=C.UTF-8

ENV LC_ALL=C.UTF-8`) in the Dockerfile, which caused a different failure in 'bad' deployments and succeeded in 'clean' deployments. However, I still don't know the actual root cause.

Loading...