-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changed the webpack devtool setting to be eval-source-map #109
Conversation
This allows us to debug with source maps when developing
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks! |
I couldn't find the CLA earlier, but I've clicked your link and filled it out. |
I would love to get this in but it has a significant downside: in my testing this completely breaks breakpoints in Chrome, especially during startup. So if I put a breakpoint in component's render method, it won't stop there after next refresh. This is a deal breaker for us. I suggest either figuring out why this happens (and maybe filing a chrome issue) or working to improve Babel transpiles output so it's more pleasant to work with. Please let me know if I'm wrong about this but I think i tested all options, and only eval and source-map works with breakpoints, source-map being terribly slow. |
I'll see where I can get on the breakpoints for eval-source-map. It's really hard thing to pick between performance and being able to debug. The current goal here is not to expose configuration, right? Otherwise it would be nice to toggle between them if you need a more pleasant, unbundled debugging experience. For reference: webpack/webpack#2145 |
In the order of importance to us:
Making this an option just means people will pick the wrong option for them and keep scratching their heads, or be unaware that an option exists. If output from Babel is hard to read we should fix Babel. If browsers fail to breakpoint with some types of sourcemaps we should file issues with browsers. All the while choosing the best option we have based on criteria above. |
Great points. |
That said, at our company sourcemaps in the browsers are working. I am not sure what is going on here. I am positive this can be solved changing some code. |
Most people expect debugger UI to work, not just debugger statements. (In fact many people don't know debugger statements exist, and only use UI.) We want to avoid switches as much as possible. This project should not turn into another Webpack. Every switch is a cognitive load on the user. They have to feel anxious if they have chosen the right option, try different options, etc, rather than just work on the app. If you're comfortable configuring things you might want to "eject" early and do that. Some people might prefer sourcemaps. But we need to pick for everyone. And in this case we would rather break convenience than break features. Otherwise the takeaway for beginners will be "breakpoints don't work in React apps". I understand this may not be very convenient. Please help us (and underlying projects) find ways to solve this. But please bear in mind that the goal of this project is to have no configuration. |
I don't know the right place to ask about this, but a recent chrome dev-tool upgrade says that it can deal with ES6 modules now. does that change anything about create-react-app debugging in chrome. And, what should my chrome dev-tool configuration settings be to best support create-react-app debugging? |
This allows us to debug with source maps when developing