When running the development server using npm start
, it throws an error and exits whenever a src file is edited in emacs. Emacs creates a file lock in the same directory as the file being edited. The file lock is a symlink to a non-existant file that has the same name as the file being edited, except it is preprended with .#
. The server sees this file, tries to compile it and throws an error because the file doesn't actually exist.
In babel.config.json
I have
{
"ignore": [ "**/.#*"]
}
and in tsconfig.json
I have
{
"compilerOptions": {
"target": "es5",
"lib": [
"dom",
"dom.iterable",
"esnext"
],
"allowJs": true,
"skipLibCheck": true,
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
"strict": true,
"forceConsistentCasingInFileNames": true,
"module": "esnext",
"moduleResolution": "node",
"noImplicitAny": true,
"resolveJsonModule": true,
"isolatedModules": true,
"noEmit": true,
"jsx": "react"
},
"include": [
"src"
],
"exclude": ["**/.#*"]
}
which is the default generated by create-react-app with the exception of the exclude
option. Both the ignore
and exclude
options have no affect.
I still see the issue.
$ npm --version
6.14.5
I searched the docs and issues for problems created by lock files and how to exclude files from building. I also searched the docs for typescript and babel.
$ npx create-react-app --info
npx: installed 98 in 6.797s
Environment Info:
current version of create-react-app: 3.4.1
running from /path/to/.npm/_npx/20905/lib/node_modules/create-react-app
System:
OS: Linux 4.19 Debian GNU/Linux 10 (buster) 10 (buster)
CPU: (4) x64 Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
Binaries:
Node: 10.19.0 - /usr/bin/node
Yarn: Not Found
npm: 6.14.5 - /usr/local/bin/npm
Browsers:
Chrome: Not Found
Firefox: 68.8.0esr
npmPackages:
react: ^16.13.1 => 16.13.1
react-dom: ^16.13.1 => 16.13.1
react-scripts: 3.4.1 => 3.4.1
npmGlobalPackages:
create-react-app: Not Found
create-react-app
.npm start
.ts
/tsx
fileI expect the tool to either ignore the lock files because they aren't being imported by anything or to honor the rules in tsconfig.json
or babel.config.json
. Before migrating to create-react-app
I was using just webpack and typescript for development/bundling and there were no issues with emacs lock files.
The dev server starts properly and compiles the project fine, but once a source file is edited it throws an error and exits.
> [email protected] front-end /path/to/project
> react-scripts start
ℹ 「wds」: Project is running at http://192.168.0.19/
ℹ 「wds」: webpack output is served from
ℹ 「wds」: Content not from webpack is served from /path/to/project/public
ℹ 「wds」: 404s will fallback to /
Starting the development server...
Files successfully emitted, waiting for typecheck results...
Compiled with warnings.
...
Search for the keywords to learn more about each warning.
To ignore, add // eslint-disable-next-line to the line before.
/path/to/project/node_modules/react-scripts/scripts/start.js:19
throw err;
^
Error: ENOENT: no such file or directory, stat '/path/to/project/src/components/.#view.ts'
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] front-end: `react-scripts start`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] front-end script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /path/to/debug.log
This started today for me too. I can't see what changed in my environment.
A temporary workaround, until this is resolved, is to tell your Emacs to stop saving lock files:
Try:
M-X Eval Expression
(setq create-lockfiles nil)
This has consequences, but will at least let us work for now with Emacs and React until someone figures out what's really going on.
same here, I tried to extend devServer/watchOptions/ignored
using customize-cra
to ignore lock files but does not work
just a temporay workaround.
Try:
Change the file /node_modules/react-scripts/scripts/start.js
.....
process.on('unhandledRejection', err => {
const re = /ENOENT: no such file or directory, stat .*\.#.*\.ts/i;
if (!err.message.match(re)) {
throw err;
}
});
....
Any progress on this? Does anyone know where the webpack config file is so that an exclude can be included?
BTW: temporary workaround suggested in above should test for [jt]s at end so editting of regular js files also works. And, also handle lstat error e.g,
const re = /ENOENT: no such file or directory, l?stat .*\.#.*\.[jt]s/i;
@seth4618 I believe it's at packages/react-scripts/config/webpack.config.js
. When i was initially messing about trying to fix this, I made changes there, but it didn't work. I probably missed something though.
@smitchell556 The fix suggested by @misapprehand with my mods is working for me.
The attempts I made were to exclude/ignore the files, not ignore the error. I'm glad that works though!
setting watchOptions.ignored
worked for me:
```javascript
watchOptions: {
ignored: /.#|node_modules|~$/,
},
````
this will ignore emacs lock files, emacs backup files, and node_modules
(which you may or may not want).
@orzechowskid Is that in the webpack config under react-scripts
or in your own config file?
ah, sorry about that. this is node_modules/react-scripts/config/webpackDevServer.config.js
, or just config/webpackDevServer.config.js
if you've ejected your app.
Cool, that seems like a good way to fix this since it’s directly through webpack’s config. It looks like there’s been discussion (#6303) about allowing custom configuration which would be ideal for this, but there’s no current support for it.
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.
ah, sorry about that. this is
node_modules/react-scripts/config/webpackDevServer.config.js
, or justconfig/webpackDevServer.config.js
if you've ejected your app.
So there is no good way getting around this without ejecting?
You could try patching it as part of the set up process. It’s not ideal but it’s just a one and done thing for each project.
Edit: then you wouldn’t need to eject and it can be scripted into the set up workflow. Ejecting seems like overkill for this.
This started today for me too. I can't see what changed in my environment.
A temporary workaround, until this is resolved, is to tell your Emacs to stop saving lock files:
Try:
M-X Eval Expression (setq create-lockfiles nil)
This has consequences, but will at least let us work for now with Emacs and React until someone figures out what's really going on.
Also the lockfiles can be disabled per project https://stackoverflow.com/questions/62567370/reactjs-local-server-crashes-after-editing-file-in-emacs-even-without-saving
You could try patching it as part of the set up process. It’s not ideal but it’s just a one and done thing for each project.
Edit: then you wouldn’t need to eject and it can be scripted into the set up workflow. Ejecting seems like overkill for this.
patching is what I ended up doing on my one c-r-a project, yeah; I added a postinstall script which mangles the webpack config file to add this fix. it's dirty but it'll work and you don't have to eject.
I couldn't get this to work too and didn't want to use the exact solution to disable symlinks: https://github.com/facebook/create-react-app/issues/9056#issuecomment-633540572.
Spacemacs docs have this in their README https://develop.spacemacs.org/layers/LAYERS.html#emberjs:
Additionally, temporary backup, autosave, and lockfiles interfere with broccoli watcher, so they need to either be moved out of the way or disabled.
(setq backup-directory-alist `((".*" . ,temporary-file-directory)))
(setq auto-save-file-name-transforms `((".*" ,temporary-file-directory t)))
(setq create-lockfiles nil)
It's still bad but at least it's something more.
I think it's an issue with watchpack
but I didn't dig into sources.
See also: https://stackoverflow.com/a/62571200
You can disable lockfiles locally:
;; .dir-locals.el in the project root
((nil . ((create-lockfiles . nil))))
Another way to reproduce the issue:
$ yarn create react-app my-app
$ cd my-app
$ yarn start
`
Edit index.js using emacs. No issue.
Then
$ rm yarn.lock
$ rm -rf node_modules
$ yarn
$ yarn start
Eidt index.js again. The server is broken by emacs lock file
After comparing two yarn.lock files. The different version of watchpack causes the issue
no issue:
watchpack@^1.6.0:
version "1.6.0"
issue:
watchpack@^1.6.0:
version "1.7.4"
If change issue yarn.lock to
watchpack@^1.6.0:
version "1.6.0"
resolved "https://registry.yarnpkg.com/watchpack/-/watchpack-1.6.0.tgz#4bc12c2ebe8aa277a71f1d3f14d685c7b446cd00"
integrity sha512-i6dHe3EyLjMmDlU1/bGQpEw25XSjkJULPuAVKCbNRefQVq48yXKUpwg538F7AZTf9kyr57zj++pQFltUa5H7yA==
dependencies:
chokidar "^2.0.2"
graceful-fs "^4.1.2"
neo-async "^2.5.0"
server will not be broken by emacs file lock
I also find
yarn create react-app my-app
and
rm yarn.lock
yarn
get different react-script under node_modules,
Especially the path of babel related package.
I am facing this too.
I do not wish to edit webpackDevserver.config.js on every project, nor do I wish to edit anything in node_modules, which is clearly meant to be ephemeral, deletable, reproducable, and isn't added to my git repo
What I do want to do is edit using emacs, without having to break emacs by removing its locking files.
I can confirm that @misapprehand's suggestion to change watchpack to version 1.6.0 seems to fix this issue...
I wonder if this watchpack issue is related: https://github.com/webpack/watchpack/issues/165
Most helpful comment
This started today for me too. I can't see what changed in my environment.
A temporary workaround, until this is resolved, is to tell your Emacs to stop saving lock files:
Try:
This has consequences, but will at least let us work for now with Emacs and React until someone figures out what's really going on.