codesandbox / codesandbox/codesandbox-client
tsconfig.json fails to save, wrong version returns after server restart
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 13.6k
- Forks
- 2.4k
- Avg merge
- 6d 19h
- Merged PRs (30d)
- 2
Description
🐛 bug report
Description of the problem
I'm trying to save a tsconfig file with module: "nodenext" under Typescript@next. The UI claims it is saved, but after a server restart or leaving for an hour and coming back, the old version of TSConfig returns claiming I edited it, this usually breaks the sandbox. The zombie files comes back even after deleting the cache and logging back in.
Related to #5598
How has this issue affected you? What are you trying to accomplish?
Hours of lost work debugging phantom zombie files like package.json, .gitignore and tsconfig.json
To Reproduce
- remove moduleResolution from tsconfig and set module to nodenext.
- set package.json to typescript@next
- Have a devDependency
Your Environment
| Software | Name/Version |
|---|---|
| Сodesandbox | 9de2de33b |
| Browser | Chrome |
| Operating System | ChromeOS |
Workaround
Remove devDependencies and peerDependencies if possible, the wreak havoc on CSB sync causing zombie config files to revert. Keep duplicate copies of tsconfig.json, package.json and .gitignore to undo potential damage from CSB's very very broken workdir sync. Also, deleting directories never deletes the workdir directory or any of it's files... this is really unexpected.
A documentation article explaining how CSB's three layer workdir sync process works and why it is so bad would be very helpful. I've resorted to never editing package.json using the UI and instead using vim to modify a backup and overwrite the real version in the container.
Sleuthing
Probably related unusual message:


@CompuIves code in actions.ts, modulePos returns -1 and crashes on the next line
if (newModule) {
if (oldModule) {
const modulePos = oldSandbox.modules.indexOf(oldModule);
Object.assign(oldSandbox.modules[modulePos], newModule);
} else {
oldSandbox.modules.push(newModule);
}
}
It seemed to be exacerbated by a devDependency after the typescript@next dependency
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the sync failure with module set to nodenext, typescript@next, and a devDependency. Start in packages/app/src/app/overmind/namespaces/files/actions.ts around line 922, then trace the workdir sync path and the modulePos lookup. Done means saved tsconfig.json and related files remain current after a restart without zombie files returning or the sync action crashing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- devtools, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100