Open nerdcity opened 5 years ago
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.
I'm having the same issue. Working with react-scripts 2.0.5
facing same issue here.
I'm hitting this issue as well. Only happens in Chrome, not Firefox. Chrome has a long history of issues with sourcemaps, and I found that changing webpack's source map type from cheap-module-source-map
to eval-source-map
fixes the issue. Fortunately, that change has already been made at https://github.com/facebook/create-react-app/pull/5060, it just hasn't made it into a release yet.
@jasonLaster @Timer (sorry if you're the wrong people to ping), any chance we can get a patch release with that fix? (This feels like a pretty major issue.)
@russelldavis a release should be out shortly :)
This is now released. 😄
Reverted due to a bug in webpack.
Is there a timeline for this release or are you waiting for webpack to fix their issues? I have the same problem, if you close dev tools then reopen them it works again, but only once.
👍 same problem
/cc @russelldavis Somebody can create reproducible test repo for https://github.com/facebook/create-react-app/issues/6433 in webpack repo, looks like a bug what we need fix
This issue is killing me
Debugging in Chrome is unusable right now. This is major showstopper.
@Timer @ianschmitz can you help the community understand the prioritization of this issue? Breakpoints being unusable in CRA apps seems like it should be a top priority, but empirically it doesn't seem to be.
Does Facebook not use CRA internally? Does Facebook not use breakpoints internally? Are breakpoints just not considered a critical feature? Something else entirely?
Thanks!
Switching source-maps from cheap-module-source-map to eval-source-map breaks the error overlay functionality. We can't really have one fix breaking other things, so that change was reverted for now. You can pin react-scripts to 2.1.4 if you need to have Chrome debugging functionality. I have an issue open at Webpack to look at this https://github.com/webpack/webpack/issues/8910, feel free to subscribe to it for any updates.
This project is maintained by a team of volunteers that don't work at Facebook (AFAIK). I can tell you that Facebook also doesn't use CRA internally.
@bugzpodder
Switching source-maps from cheap-module-source-map to eval-source-map breaks the error overlay functionality. We can't really have one fix breaking other things, so that change was reverted for now. You can pin react-scripts to 2.1.4 if you need to have Chrome debugging functionality. I have an issue open at Webpack to look at this webpack/webpack#8910, feel free to subscribe to it for any updates.
This project is maintained by a team of volunteers that don't work at Facebook (AFAIK). I can tell you that Facebook also doesn't use CRA internally.
How to
Switching source-maps from cheap-module-source-map to eval-source-map
??
Where does webpack config live in the app?
Goto node_modules/react-scripts/config/webpack.config.js, look up cheap-module-source-map and change to eval-source-map. This is temporary and you'll have to do this every time you change your package configuration.
I've used this tool to override cheap-module-source-map
with eval-source-map
https://github.com/arackaf/customize-cra
looking forward to a permanent fix though, since this is indeed a heavy handed work around. Also, when using eval-source-map
and doing CMD + P in the debugger to find files, it will search through the minified files as well as the source mapped ones, which is definitely not ideal :\
Using this to the package.json
worked for me: "start:debug": "react-scripts --inspect start --no-cache --runInBand",
Does anyone have the same issue after upgrading to CRA 3.x? This still seems to be an issue in CRA 3.x?
@jsdevtom worked! but why??
Doesn't work with 3.0 for me as well, very annoying and I have no clue how to fix it
@hmeerlo read @jsdevtom 's solution. it works
@adamchenwei Ah sorry, I focused on @bugzpodder solution but that was a workaround that stops working every now and then. This one does work indeed, thanks.
Thank you @jsdevtom . It has been so stressful to develop like this until now in Chrome
@adamchenwei I don't know, I haven't delved in to the react scripts enough to find out. @miggu You're very welcome
Please be aware that I consider this a temporary solution. The breakpoints still fail for me after an error is thrown in the app. On average I would say I can debug develop for about 30 minutes before I need to run the command again and thus hit the breakpoints.
I did the v2 revert solution as described by @bugzpodder. Works so far. Hopefully issue will be fixed soon tho.
@jsdevtom
Using this to the package.json worked for me: "start:debug":
How do you start the app then?
$ npm start ?
$ npm run start:debug ?
I ended up working around this by using react-app-rewired. I am running react-scripts 3.0.1.
Steps:
npm install react-app-rewired --save-dev
or yarn add react-app-rewired --dev
config-overrides.js
config-overrides.js
:
module.exports = function override(config, env) {
if (env !== 'production') {
config = { ...config, ...{ devtool: 'cheap-module-eval-source-map' } };
}
return config;
}
"scripts": {
"start": "react-app-rewired start",
"build": "react-app-rewired build",
"test": "react-app-rewired test",
"eject": "react-app-rewired eject"
},
I'm just wondering why everyone is trying to replace the devtool with eval-source-map
, there are many devtools available and cheap-module-eval-source-map
seems to work fine for me, unless I'm missing something.
@j3ko The error overlay displays wrong lines if cheap-module-eval-source-map is used.
@jsdevtom
Using this to the package.json worked for me: "start:debug":
How do you start the app then?
$ npm start ? $ npm run start:debug ?
You use npm run start:debug
. Here is the respective documentation: https://docs.npmjs.com/cli/run-script.html
I've still encountered this issue even when using solution presented by @jsdevtom . The only sure fire way I can set breakpoints is by using debugger;
in code. It's not as pleasant as just setting the point in devtools, but it makes things predictable at least.
I still have this problem, is there any solution for this issue?
Try this package https://www.npmjs.com/package/react-breakpoint-fix
just install the package and run react-breakpoint-fix from the terminal.
This fixed it for me. I'm using react-scripts@3.x
Try this package https://www.npmjs.com/package/react-breakpoint-fix
just install the package and run react-breakpoint-fix from the terminal.
This fixed it for me. I'm using react-scripts@3.x
If you can use cheap-eval sure. I'm not sure adding a dependency to regex the eval tool to the cheap one is so wise. I definitely know this would not fly within my team.
I think it can be fixed if we will be able to choose sourcemap type via environment variable. https://github.com/facebook/create-react-app/issues/7495
So to clarify, is this still an issue? As someone looking to use the react-error-overlay
plugin in a non-CRA app[1] (which already has full control of the sourcemap devtool) , this comment from @russelldavis seems concerning: https://github.com/facebook/create-react-app/issues/6433#issuecomment-464414558
It seems like there's no current way to have fully working sourcemaps as well as react-error-overlay
working in an app?
All of the comments in this thread mainly discuss switching the sourcemap type in webpack, but don't seem to take into account that this will seemingly reintroduce #6433. Curious what the current state is and whether there's an open webpack issue somewhere if it's indeed a webpack bug.
[1] (or perhaps investigate using it as part of a React fast-refresh implementation: https://github.com/facebook/react/issues/16604#issuecomment-528663101)
I can confirm that this is still an issue occasionally. I just ran into it again, even using the start:debug solution of @jsdevtom . I have no clue what to do to work around it, except using debugger statements.
Also confirming that this is still an issue even with @jsdevtom's fix. I'm having to restart my app to get debugging work again after a hot reload.
Just to confirm, unless every line of my program is actually in a file named fs.js and of which all are the seventh line (which is definitely not the case 😉), this is indeed still broken.
@RobertWHurst - fix is merged so it should be in the next react-scripts
release. Keep your eye on npm outdated
.
@justingrant That's great to hear. will do 👍
Still facing this issue as well.
@RobertWHurst - turns out that the fix in #7022 isn't the same issue as this one. This problem is still happening. FWIW, what I've seen in the past is that there are three separate (maybe related) problems in this area: 1) Breakpoints are not adjusted when you add new lines of code above an existing breakpoint and then do a hot update. For example, if you have a breakpoint on line 100 and you insert 2 lines between lines 98 and 99, then the breakpoint may not move to 102 as expected. It might stick on line 100, even through the "new" line 100 is not the same code as the "old" line 100. 2) If you save a file in VSCode while the VSCode debugger is paused at a breakpoint, then some breakpoints won't work properly in the hot-updated file after you continue, where "won't work properly" means that you can't set breakpoints on valid code lines, you can set breakpoints on whitespace lines in the new file, etc. For this reason, I don't save changes while the debugger is stopped at a breakpoint. 3) If you run your app in the VSCode debugger while also having the same app open in Chrome Dev Tools, then you'll sometimes get "zombie" breakpoints where code execution will stop on a line that doesn't have a breakpoint on it in VSCode. It's possible that this is the same problem as (2) above-- it might only happen when you save changes in VSCode while the app is stopped in the VSCode debugger and while the Chrome dev tools are open in the browser.
In all cases, restarting the debug session (stop debugging, stop the npm start
process, restart the npm start
process, and start debugging again) will fix the problem.
I haven't done the validation to figure out reliable repro cases for all these, so it's possible that all three of these are the same root cause.
Hope this info is helpful. It looks like this issue and #8165 both reflect some (maybe all) of the problems that I described above.
Given that there's a completely new hot-reload solution called Fast Refresh coming to React (it's already been released for React Native), it's possible that no fixes will be made for the current hot-reload solution.
Does anyone know if there's an existing CRA issue that's tracking adoption of the new Fast Refresh solution in CRA? I wasn't able to find one.
@bugzpodder Would you know what's so special about 2.1.4 that make it work with chrome while others not? Can't we just apply that change to the CRA? (I scanned through some of the links, still did not seems to find a real solution)
also why This project is maintained by a team of volunteers that don't work at Facebook (AFAIK). I can tell you that Facebook also doesn't use CRA internally.
if its still under org of Facebook, but it does not maintain it....?
Hi, has anyone had any luck with this?
Breakpoints still are not working in react-scripts 3.3.1. I tried @jsdevtom 's solution but it did't make any difference, also tried a variety of source map configs in webpack's devtool property.
It's getting really frustrating
UPDATE: I also tried downgrading react-scripts to 2.1.4 and breakpoints are still not working as expected...
@bugzpodder Would you know what's so special about 2.1.4 that make it work with chrome while others not? Can't we just apply that change to the CRA? (I scanned through some of the links, still did not seems to find a real solution)
2.1.4 was working possibly because of #5060, you can use react-app-rewired
to patch webpack config if you wishes to do so.
also why
This project is maintained by a team of volunteers that don't work at Facebook (AFAIK). I can tell you that Facebook also doesn't use CRA internally.
if its still under org of Facebook, but it does not maintain it....?
Yes, but they are under no obligation to give it up. You'll have to take it up with someone who works there currently.
Still having this same issue with react script 3.3.0, the breakpoints works just sometimes with no apparent pattern
Same issue for me with:
seems to work randomly.
Adding the no-cache flag to the start script npm command doesn't help, as suggested here: CRA chrome issue solution
Same issue here. Running:
With Firefox 75 it works fine, though.
Not sure if it's related, but I am facing the issue without using react-scripts. I am only using react-hot-loader (4.12.18)
Is this a bug report?
yes
Did you try recovering your dependencies?
test-cra $npm --version 5.6.0
test-cra $yarn --version 1.12.3
Which terms did you search for in User Guide?
I looked for "hot-update" and "breakpoint"
Environment
System: OS: macOS High Sierra 10.13.6 CPU: x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz Binaries: Node: 8.11.1 - ~/.nvm/versions/node/v8.11.1/bin/node Yarn: 1.12.3 - /usr/local/bin/yarn npm: 5.6.0 - ~/.nvm/versions/node/v8.11.1/bin/npm Browsers: Chrome: 71.0.3578.98 Firefox: 63.0.1 Safari: 11.1.2 npmPackages: react: ^16.7.0 => 16.7.0 react-dom: ^16.7.0 => 16.7.0 react-scripts: 2.1.1 => 2.1.1 npmGlobalPackages: create-react-app: Not Found
Steps to Reproduce
** this is all good, and I am able to repeat steps 8-10 successfully any number of times
class App extends Component { render() { return (
Edit
Learn Reactsrc/App.js
and save to reload.}
foo = 'bar'; }
export default App;