Develop Reference

Exclude Script files from loading w/ Dev Tools

I have a migrated SharePoint application that brought over a bunch of old JavaScript files. One of these files is causing errors in the new environment but I'm unsure of the culprit. They aren't throwing console errors, but rather modifying elements by adding unwanted attributes and classes
Is there a way to prevent the loading of individual .js files without modifying the source? I know blackboxing will prevent the debugger from stepping into the code, but it still loads. If I can narrow it down to one file, I can fix the conflicts that are occurring

Another solution is using Fiddler (http://www.telerik.com/fiddler). It allows you to isolate particular js files and either force them not load, or it allows you to inject your own local JavaScript files on the fly. This way you don't have to migrate your project/solution locally for testing, you can continue to run this on your sharepoint server, and use your own local JS files..
Good luck!!

For the record, this can now be done directly in Chrome Devtools as of version 59.
Load the page, open devtools, then click the network tab. Find the request you'd like to block, right click on it, then select "Block request URL" & reload the page. That resource will be blocked this time around.
Very useful!

Ok, posting this as an answer:
Although intended for other uses, AdBlock Plus can do what you're asking, and it's available for all major browsers.
Just set up a filter like example.com/path/to/your.js and that script should no longer get loaded.

What is the purpose of source maps?

Can someone please explain what the point is of source maps? Because as I see it, my concatenated and minified file gets loaded (talking about JavaScript), alongside 100+ modules. How is this not affecting performance when I'm loading twice the size as before?

The point of a source map is that you can run minified Javascript or transpiled Javascript (which is not particularly readable in a debugger by itself), but when you open the debugger, the source map is loaded by the debugger and it gives you a readable form of your source for debugging purposes. The source map is not loaded if the browser is not configured for source map debugging.
Source maps are also extremely useful if you are transpiling code from something like TypeScript or ES6 down to ES5 Javascript so you can see the actual code that you wrote originally in the debugger rather than only the transpiled and minified output.
The alternative before the days of source maps was to have separate versions of your site or options on your site that would load non-minified JS so that you could debug with normal symbols, but this of course isn't actually debugging the exact same code so even then, this could still leave you having to try to debug minified code.
You can read here about how source maps are enabled in the Chrome debugger. If you're watching what is downloaded by the browser, then make sure that you are using a browser that does not have source maps enabled when checking if they are downloaded.

Because you only load the sourcemap when you open the debugger.
Actual users, who don't open the debugger, still get the benefit of the minification.

A source map is a developer tool. It's practical to know the original source when an error occurs within minified source, so you can track down the source of the error.
Source maps are thus only loaded by debuggers, and will not be loaded by default. However, you should consider disabling source maps for production environments, because debug data usually shouldn't be on production environments: for performance and (more importantly) security reasons

Finding actual source file line number when JavaScript Error occurs?

What is the industry standard or professional process of finding out where the actual line number in the source code of your rendered page is happening?
I have used browser debug tools and it of course shows you the error, but the line number is not the same for the source code file that is being served up. I know that usually server side scripts are making the file longer than it really is and etc.
I usually just do a find for functions or code near the error and can eventually find it, but is there a better way?

The simplest way is to ensure that most of your JS is written in non-templated .js files, rather than inline <script> blocks in your templated html.

I develop with Visual Studio.net 2013, which will stop at breakpoints and break on server and client side errors.
If you aren't developing with a tool like VisualStudio that has a built in debugger with breakpoints, etc., the built in developer tools in Chrome and IE are awesome (IMHO). Since Javascript runs clientside, you'll need to debug it using the browser. If you don't like the built in developer tools, you can also try Fiddler and Firebug.

jQuery Map 404 Issue in Rails App Console

In one of my Rails apps I have added a local jQuery library, but I have noticed a 404 in the console.
Should one be concerned about any future bugs due to not having the "jquery map" in my app files?
Problem: GET localhost:3000/assets/jquery-latest.min.map 404 (Not Found) Error
Thanks for any feedback in advance!

This is called a source-map file. You shoudn't worry about it, it is only loaded because the developer console of your browser is open and it attempts to automatically download the corresponding source map because jQuery provides one.
As you probably already noticed, you are using the compressed/minified version of jQuery and its code code is unreadable by a human. Source-map files allows the browser to run the minified version of the script but to also download the uncompressed version and a map file that links the two together. This way, when you are debugging your code the browser will present you the full source code of jQuery including the comments.
This may not be super useful alone with jQuery unless you develop jQuery, but if you compressed all of your Javascript files this is a neat feature: instead of having a crash in a function g(y,s,w,f), your browser would download the original source and tell you the error is in doSomething(element, width, height, otherThing) and basically act work like if the code was never compressed.

Finding location of errors in minified Javascript

I am in the process of implementing a feature on a Python webserver which automatically fetches, concatenates, minifies, caches and serves Javascript files (including external ones) on first request so that users can get the benefits of minification without us having to manually run any of our Javascript through a minifier when we push changes.
However, the trouble is that our choice of minifier (slimit) introduces a syntax error somewhere in the Javascript, and (naturally) removes all newlines.
Simply knowing that there is an Unexpected token ILLEGAL somewhere in our hundreds of thousands of characters of minified Javascript is unhelpful when trying to figure out the cause of this and find a workaround.
So:
1) Is there a way, in (any) browser, that I can automatically 'prettify' Javascript when viewing it in the Developer Tools section of the browser, inserting line breaks after statements, and showing errors on the lines where they occur?
2) Alternatively, is there a clever hack I can use before returning the minified Javascript on our testing server to insert newlines at the end of statements wherever possible, in order to make it easier to find the location of the syntax error when viewing in Developer Tools?
3) Alternatively, is there some other obvious solution to my problem that I am missing?

if you are using / or can use chrome to debug then there is an option to see the minified files in pretty print
press f12 -> Sources -> Select the javascript file to debug -> select pretty print from the bottom bar.
this will set the right format will all the tabs on the minified file and probably you will be able to find the error