@tomi is that likely to be the cause of this: https://github.com/meteor/meteor/issues/6623?
Running Ubuntu 16.04 and Chrome I frequently can’t set a breakpoint where I want to. I get around it by setting it ahead of the point and stepping in.
If this behavior is due to source mapping issues as the other comments here tend to indicate and Chrome coverage is good enough to work without Babel, it would be a plus to be able to opt out of transpilation in the development environment.
3 Likes
I’ve had issues where I get some code errors that don’t use the sourcemaps (when this happens the error usually points to a console.log call deep in some Meteor core lib - not the most helpful). I think Firefox almost never uses the source maps correctly.
Additionally, it would also be nice if a deployed build contained a source map for those times when you find an error in the production bundle.
Really Awesome !
Thanks MDG.
Even Firefox has decent enough coverage that disabling Babel during dev could be very helpful.
We would lose some cool features like async/await, but the tradeoff might be worth it.
Another option could be to maybe use SystemJS like JSPM does? I haven’t debugged much in there, but it loads the modules as is, and does the compilation on the client, which could allow the modules to be selectively compiled or not. /brainstorm
Let’s make this happen!
That’s a good idea - then you can pick a browser that has support for all of the features you want for development, but still have compilation and cross-browser support in production.
2 Likes
Debugging in chrome developer tools often has the wrong breakpoints, or hitting go to next line jumps 5 or 6 lines, or goes backwards, it’s all wonky.
Being able to turn it off and on in development easily would be best!
that hasn’t been much of a problem for us. Could you provide some examples of your specific situation? Maybe we could offer some advice.
I know how to work around this. But the fact of the matter is:
Let’s say you have n comments and m users. Now you want to display the username alongside each comment.
With a JOIN sql query it’s one query and with n results. The db also only returns the data you specified, already joined by the server.
To achieve the same result in Mongodb, you have to do at least n+1 queries and you get 2n results which you then join on the client (or you use $aggregate and lose reactivity). Also, with the Meteor stack and MiniMongo, you now have to use something like publish-composite to avoid having to publish all users’ usernames.
Or you denormalize the comments and put the username in there. Which is fine as long as your application only has those two collections. As soon as you add other collections into the mix, it gets problematic - Murphy’s law will strike: You will forget to update one of those denormalized collections somewhere.
Also: If you update one user, you now also have to update all the collections’ items he touched. With a referential, normalized design a user update is one(1) query. With a de-normalized design: Who knows?
As a CoffeeScript developer for years, I know the pain of which you speak. The workaround is simple, though annoying: put a line with just debugger; exactly where you want your breakpoint, and DevTools will break there. Or if you want to be able to toggle it on/off, add a console.log line where you want the breakpoint, and set the breakpoint on that line.
Yes you need to remember to remove this debugging code when you’re done, but I don’t find that the situation comes up that often that it makes me reconsider using sourcemaps. Generally if I’m forced into tricks like this, I’ve packed too much logic into a single line of code.
2 Likes
You’re right, it is more an annoyance than a stopper. Stepping into the line usually works for me.
But, now that someone has put it into my head that transpilation during development may not be necessary, I’m considering not just this but other issues.
How much would be shaved from the turnaround time?
Also, and I’m embarrassed that I don’t know this, but would I be able to make changes in the JS within the Chrome debugger? Currently, changes don’t have an effect and I’m assuming it’s because I’m not looking at the real code. I’ve worked in interpreted environments as long ago as the early 80s that allowed me to make code changes that took instant effect right in the debugger. Don’t know why I’ve not questioned that more than I have in JS.
I haven’t tried it, but supposedly the Workspaces feature in Chrome Developer Tools enables editing source from DevTools that you can save to disk: https://developers.google.com/web/tools/setup/
Is it possible to detect capable user agents and dynamically serve a payload that contains native es6 code?
@zoltan, what are the plans for Isobuild in the long term? Will MDG continue to develop Isobuild or migrate to something else like Webpack?
5 Likes
Excited about the Node upgrade. Any estimates or targets for the release dates?
Please if you already know that fairly well be honest. Then we might as well already start migration by adopting the available package until an official version is there.
We’re thinking of using isobuild to compile package sources for distribution on npm.
We’re currently in beta for 1.3.3 . We hope to get 1.3.3 released in 2 weeks or so then get a beta out for 1.4 shortly after.
4 Likes
What about the angular2 integration?
Angular2 support is already there, but not as mature as Angular 1 or ReactJS.
1 Like