Convex dev server chokes on Emacs backup files
By default, my text editor (Emacs) saves backup files in the same directory by adding a
#
to the beginning and the end of the file name. So for instance a file called functions.ts
will generate a backup file called #functions.ts#
(which then gets removed automatically when saving the original file).
The problem is that npx convex dev
chokes on those files, it crashes with the following error message:
It actually crashes, so my functions are not kept synchronized anymore and I have to restart npx convex dev
for my functions to synchronize again, which is pretty annoying.
Sure I could configure Emacs to save the backup files somewhere else or with a different name, but it would be nice if it worked out of the box. After all the extension is .ts#
so it should not even be considered as a Typescript file by Convex?7 Replies
The extension .ts# should be skipped! Is it possible the file is named #functions.ts instead? The generated code here suggests that.
although the .ts# could be swapped here for .js... we'll fix this! Likely there's code that allows /.ts./ somewhere
No, it is called
#functions.ts#
. And I also get the same error if I just do touch "convex/#abc.txt
and then npx convex dev
, so it looks like Convex doesn’t even look at the extension at all?Looking at the code I agree https://github.com/get-convex/convex-js/blob/f39968ac595e75c2914e011c339675b470950c66/src/bundler/index.ts#L334
GitHub
convex-js/src/bundler/index.ts at f39968ac595e75c2914e011c339675b47...
TypeScript/JavaScript client library for Convex. Contribute to get-convex/convex-js development by creating an account on GitHub.
This could be limited to all possible .ts and .js extensions for now, even if long term anything esbuild can bundle should be allowed. .ts .tsx .mts .mtsx etc
This is just limiting entry points, one if these modules can still import a txt file if the bundler is configured for that.
Let's start with carving out #, being extra careful because we don't want to ignore files now we later add support for since that would break people's projects
Yes, the reason it crashes currently is because the
#
at the beginning of the filename results in syntactically invalid generated code, so I guess it’s safe to handle this particular case as it will never make sense to want that@Fractal the change for this is in, you'll see it in the next client release.
@ballingt Great, thank you!