Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

tslater
Copy link

@tslater tslater commented Jul 22, 2016

This allows us to debug with source maps when developing

This allows us to debug with source maps when developing
@ghost
Copy link

ghost commented Jul 22, 2016

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!

@tslater
Copy link
Author

tslater commented Jul 22, 2016

I couldn't find the CLA earlier, but I've clicked your link and filled it out.

@ghost ghost added the CLA Signed label Jul 22, 2016
@gaearon
Copy link
Contributor

gaearon commented Jul 22, 2016

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.

@gaearon gaearon closed this Jul 22, 2016
@tslater
Copy link
Author

tslater commented Jul 22, 2016

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

@gaearon
Copy link
Contributor

gaearon commented Jul 22, 2016

In the order of importance to us:

  • non-brokenness (eg breakpoints should work)
  • fast rebuilds
  • beautiful source

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.

@tslater
Copy link
Author

tslater commented Jul 22, 2016

Great points.

@ChrisCinelli
Copy link

debugger statements still work. Some people may prefer to have sourcemaps and having breakpoints not working. Some people also prefer to debug only with console.log. What about a switch to activate sourcemaps?

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.

@gaearon
Copy link
Contributor

gaearon commented Jul 23, 2016

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.

@Sigfried
Copy link

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?

@lock lock bot locked and limited conversation to collaborators Jan 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants