I downloaded draw.io source files from the github repository and tried to make some minor changes to the import function, but all the sources are minified (especially app.min.js).
So my question is this: is there any way to debug the code with the unminified sources?
Also I tried to pass inside the query string the param dev=1, but it gives some errors and doesn't manage to load.
I already saw the post Draw.io — Is there non-minified source? but I don't know how to build draw.io.
If you know the function that you need to edit you can use https://unminify.com to reverse the spacing minification but the variable and function names will still be simplified making it difficult (but not impossible) to edit.
I've found, in my opinon, a strange solution.
I took build.xml file and replaced all the <jscomp> instructions with <concat> so the result file isn't a minification but just a merge of all source files.
This method works just fine and it solves my problem but i don't know if there is a simpler and more right method.
I am trying to work PHP project using PhpStorm.
I am having an issue that one JavaScript file does not show up properly under Project folder.
According to Windows folder structure, this js file (bootstrap.min.js) exists on same folder (without any hierarchy structure).
But, inside PhpStorm, it shows up under other js file.
Is there any reason it behaves like this?
Is it anything to do with Bootstrap?
This is a new-ish thing with PHPStorm (and the rest of the family).
In general, something.min.js is the code minified version of something.js, and you generally don't care to ever open the minified version in your editor.
So, PHPStorm shows it under the one that has the unminified, human-readable version of the code.
It's not actually changing the file system at all, it's just trying to help clean up the Project window a bit.
But, inside PhpStorm, it shows up under other js file.
It's called "nesting" and it's purely visual thing -- no changes at actual file system level.
It's convenient when you have source and processed/generated files (e.g. TypeScript source and generated .js and .map files; Sass source and generated .css and .map files etc). This way you see only source (in which you are interested the most for editing purposes) and generated files are hidden (so more files can fit the screen).
Is it anything to do with Bootstrap?
No.
You can create another file (e.g. test.js and test.min.js) and it will be nested in a similar fashion.
Is there any reason it behaves like this?
It's a relatively new feature (v2016.3 or so).
To be precise it's an old feature (PhpStorm v6 or so) .. but before it worked based on File Watcher settings (and file must have been processed by File Watcher in order to be nested) .. while now (since 2016.3 I believe) it's completely separate functionality and matching happens by simple patterns.
As of 2017.2 IIRC you can edit those patterns as you wish (in earlier versions they were hardcoded) -- just choose File Nesting... in Project View panel content menu (e.g. under "cog" icon).
The following article explains that in order to find the source map of a JavaScript file such as jQuery, the web browser looks inside the JavaScript code and looks for the line containing the sourceMappingURL directive embedded in a JavaScript comment. For instance, the jQuery 1.9.0 minified file contains such a directive at the end of a file. However, the more recent jQuery 1.11.1 minified distribution does not contain such a directive, but a jQuery 1.11.1 map file is also distributed with this (final stable jQuery 1) version. So how does the web browser find the map file for the minified file.
I guess the convention of web browsers looking for the sourceMappingURL directive was dropped in favor of following the naming convention of looking for a file of the same name, with .js replaced by .min. Is this what happened?
According to the documentation for the recently released Firefox Developer Edition, such browser still seems to be looking for the sourceMappingURL directive.
Thanks.
The reasoning behind dropping source mapping from recent versions is described on the JQuery blog
This release does not contain the sourcemap comment in the minified
file. Sourcemaps have proven to be a very problematic and puzzling
thing to developers, spawning hundreds of confused developers on
forums like StackOverflow and causing some to think jQuery itself was
broken.
We’ll still be generating and distributing sourcemaps, but you will
need to add the appropriate sourcemap comment at the end of the
minified file if the browser does not support manually associating map
files (currently, none do). If you generate your own jQuery file using
the custom build process, the sourcemap comment will be present in the
minified file and the map is generated; you can either leave it in and
use sourcemaps or edit it out and ignore the map file entirely.
We hope to bring back and improve sourcemap support in the future, but
at the moment neither the design nor the implementation seem suited
for situations like jQuery’s, where there are widely distributed files
on CDNs. We’d like sourcemaps (and browsers supporting them) to
gracefully handle situations like file renaming or missing files. See
our bug ticket for more information.
I bundle all my JS assets into one minified uglified file via r.js (part of requirejs).
If any unhandled errors occur on the browser, I use raygun (like Airbrake) to report it back to me. The only problem is the line number I get in my error message, refers to the bundled minified file. Which doesn't help much.
Is there a way to correctly map the line number of my single minified and uglified bundled asset, into the individual JS file with the correct line number?
The first thing you need to do is have r.js generate a source map of the bundle. To do this, in the options you pass to r.js you need to have the option generateSourceMaps set to true and you must set the optimize option to "uglify2" or
"closure" with a closure compiler jar build after r1592 (20111114 release)."
(I'm citing from this documentation.) I've done it with optimize set to "uglify2" and was able to get decent references to the original source code in Chrome.
The logging service must also support it. This post over at the raygun forums suggests that raygun does not yet support source maps.
Someone created a list of such services as a gist over at github. Some of the services are marked as supporting source maps. I can't vouch for its accuracy but it could be a good starting point to find a service that supports it.
Often, when working with jQuery, the need arises to include multiple plugins. This can quickly become messy work, especially when some plugins require additional components (images and CSS files).
What are some of the "recommended" ways to:
a. Manage the required files/components (.js, .css and images) in a way that is easy to maintain, and;
b. Keep these plugin packages updated to the latest versions
I'm not necessarily looking for a tool to do this (although one that could perform this management would be useful, I suppose), but more of a way of thinking.
Update: These days there is Bower, Component and Browserify which take care of all of the following for us automatically.
I'm surprised no one has covered what I do yet. So here's how I manage scripts and resources.
I have each project I work on setup with SVN. Nearly all of the scripts I include have a SVN mirror (github has svn these days) this means that I can then use SVN externals and fetch whatever branch or version or whatever I want of that project directly into the projects scripts folder. As we are using SVN, it is easy to track, manage and update these scripts.
If a project is not on SVN, then I just add it to a common SVN project I have made, so for instance Project A and Project B, both use jquery-project-not-in-svn, so we stick jquery-project-not-in-svn into our common project's SVN repository, and then use SVN externals on Projects A and B to reference it - as explained before.
Now that covers managing, fetching and updating.
Here is how I cover script inclusions and requests.
As each project now has it's own scripts directory that contains all the scripts it needs (which is managed by SVN externals), we now have to worry about minifying them to reduce load on our server. Each project has a Makefile in it's root, which contains the command update. This command will perform the following:
Perform a SVN update (this will update all SVN externals appropriately)
Once that is done, it will pack and minify all the js files into scripts/all.js and scripts/all.min.js
I can't share the exact Makefile but I can share one which is public that handles packing/merging and minification of CSS and Javascript. Here is the link:
http://github.com/balupton/jquery-sparkle/blob/9921fcbf1cbeab7a4f2f875a91cb8548f3f65721/Makefile
By doing these things, we have achieved:
Management of external script resources over multiple projects
Updating of appropriate script resources automatically
Packing all used script resources of the project into one file
Minifying that file, such that only one JS request and one CSS request are performed.
So good luckmate, feel free to post a comment if you would like to learn more.
I would recommend not updating them unless you are experiencing a problem with the version you have or you would like to use a new feature available in the updated plugin. As the saying goes, if it ain't broke, don't fix it.
My own personal "recommended" way is to keep all my JavaScript files in one include folder, all CSS files in another, and all images in a third directory. I write shortcut functions for my projects that I can then use like <?php scriptlink( 'jquery.tooltip' ); ?> or <?php stylelink( 'jquery.thickbox' ); ?>. Each shortcut function takes a filename (only) as an argument and outputs the full HTML tag for that resource type, i.e. (in order) <script type="text/javascript" src="/includes/js/jquery.tooltip.js"></script> or <link rel="stylesheet" href="/includes/css/jquery.thickbox.css" />
Most jQuery plugins I've run across that require images allow either specifying a configuration variable in the script itself or in the code used to invoke the plugin. Stylesheets are quite easily included without mucking about with the script.
So far this method has kept me pretty sane, so I think it works rather well. I don't tear my hair out over where I stuck a particular plugin; I just include it with a function. (The system also supports subdirectories of the include directory, so e.g. <?php scriptlink( 'ui/accordion' ); ?> equals <script type="text/javascript" src="/includes/js/ui/accordion.js"></script>.)
YMMV of course, but the only issue I've had at all is with upgrades when plugin authors start distributing a jquery.plugin.pack.js version instead of jquery.plugin.min.js or vice versa, because I actually have to remember to change the filenames I look for.
(Since I've omitted the implementation of those simple functions, perhaps your version will check for different variants of the file name given. If the argument to scriptlink() is jquery.plugin, the function might check the file system to see if jquery.plugin.pack.js exists, and if not look for jquery.plugin.min.js, and if not look for jquery.plugin.js, etc.)
CDNs are great but not for debugging. Sometimes debugging really requires local access
to the scripts and CDNs are useless until in production mode. For this reason I still like
to keep both debug and minified versions around then compare results and benchmark response time until we shift to production.
All of my jQuery plugins are organised into subfolders which include the version number e.g.
/assets/js/plugin.1.4.1/plugin.1.4.1.min.js
/assets/js/plugin.1.4.1/images/image.gif
If I need to update to 1.4.2 I can drop it in a new folder without too many problem, I can even use a specific version of the plugin in different parts of the site if needed. When I site is large and your using a few different plugins it's helpful to quickly see version numbers without digging around source comments in a plugin.js file.
If a plugin requires CSS I will take the base styles out of the plugin CSS and bundle these in with my main stylesheet, requesting additional CSS files is expensive and 9 times out of 10 it will be customised anyway. Likewise with images, if I'm doing any image customisation I will bundle these into my main image sprite, otherwise I'll just link to the images into that plugin.1.4.1 directory.
Yes, you end up with a few more files in your repo but it means:
you can easily upgrade plugins just by updating your paths
you can debug plugin issues easier because you can see how out of date you are
you can roll back to an earlier version if everything breaks
You could utilize the Google CDN (Content Delivery Network) for more popular plug-ins. Google keeps it up-to-date, you can quickly choose/switch between versions, and you also get the benefits of caching from other websites that use CDN.
Example for jQuery:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.0/jquery.min.js"></script>
And, if you want to use a higher version automatically, change the version to 1.4 (automatic 1.4.x updates) or even 1 (automatic 1.x.x updates). Unfortunately not all plug-ins are available, but many of the major ones are.