Today I learned that it is possible to include source maps directly into your minified JavaScript file instead of having them in a separate example.min.map file. I wonder: why would anybody want to do something like that?
The benefit of having source maps is clear to me: one can for example debug errors with the original, non-compressed source files while running the minified files. The benefit of minimization is also clear: the size of source files is greatly reduced, making it quicker for browsers to download.
So why on Earth I would want to include the source maps into the minified file, given that the maps have size even greater than the minified code itself?
I searched around and the only reason I could see that people inline source maps is for use in development. Inlined source maps should not be used in production.
The rational for inlining the source maps with your minified files is that the browser is parsing the exact same JavaScript in development and production. Some minifiers like Closure Compiler do more than 'just' minify the code. Using the advanced options it can also do things like: dead code removal, function inlining, or aggressive variable renaming. This makes the minified code (potentially) functionally different than the source file.
This could still be done by referencing external source map files of course, but some people seem to prefer inlining for their build process.
If you are remote debugging Chrome on an android device, the Chrome debugger cannot just access any file it wants on the device and that includes separate map files. If you include them inline you don't have this issue.
JS bundling tools like Browserify or Webpack will bundle all your .js files input one or several bundles, even in developing mode. So in this case, adding inline source map to generated bundles is the easiest way to help debugging without bringing extra files.
In some situations you might want to include inline sourcemaps into evaluated code. E.g you have a coffeescript input field and you want to enable debbuging the code in coffeescript. There is a stackoverflow question about source maps in evaluated code:
Getting source maps working with evaluated code
You could include #sourceURL in your comments to specify a URL of your eval code and load a map file (see page 8 of SourceMap Spec 3). But it is not always possible to write files to some location.
If you're developing a browser extension, inline-source-map is the only option for debugging since extension itself can't access the sourcemap files -- even if it's possible you have to specify all of your sourcemap files inside the manifest.json(config file for browser extensions).
cheap-module-source-map is much better for a production build.
inline-source-map is used to make quick and dirty builds when testing
The use case (for me) is non-browser environments where source maps are not supported (or very much at all, hence the need for webpack.)
Or another way to put it, webpack without the web.
Related
I'm trying to share functions across multiple backgrounds scripts in a chrome-extension. This works easily / by design in general as long as you add the scripts to the manifest.json, then a function called from the background.js can call code in another script as long as that other script is loaded first.
HOWEVER, I've tried a few Chrome extension generator templates that have a compilation step with gulp or webpack. (e.g. This one: https://github.com/samuelsimoes/chrome-extension-webpack-boilerplate)
But unfortunately function sharing breaks in the compiled background.js scripts.
I don't know what "magic" in the chrome-extension architecture is broken when compiled code is used.
Any advice/insights on what could be preventing function sharing appreciated.
For details on the implementation e.g. webpack.config etc. please see the boilerplate as that's what I'm working with as well.
Answering my own question after some further research:
The issue appeared to be that webpack compiled each file into a module, necessitating changes to accomodate function sharing between these files.
Rather than adding module.exports statements to each background script, and having to prefix all my function references with the module name, I decided it was easier to rely on webpack (specifically the webpack-concat-plugin) to concat the background files together.
I'm trying to figure out how to set up a JavaScript development project that will allow me to factor my code into several files. I plan to run this eventually on a client web browser, but first I need to set up an efficient development environment.
I've used other programming languages before that let you keep a large number of files in a subdirectory and then let you compile everything into your final deployable (or have an interpreter do something similar). Javascript doesn't seem to allow this - I have to manually add a <script> tag for each js file to the head of my web page to get the browser to load it. This can get very hard to manage once you have more than about 10 files that you need to keep track of. It would be nice if I could write <script src="myscripts/**/*.js"> to suck in everything, at least during development time.
I've found Grunt 'uglify' which looks like it would be a handy tool for creating a final file for deployment, but during development I need to keep everything separate so I can debug properly. Is there any way to have my web page load every js file in my development directory?
As others have mentioned in comments, Webpack (or similar) is the way to go. It bundles up all of your relevant code, and can also process it for minification.
I want to address this comment though:
but during development I need to keep everything separate so I can debug properly
You don't need, or want, that. While developing, you want to be testing against the same sort of build process you'll use in a deployment later. So, how can you easily debug your compiled scripts? There's a .map file that gets built, which tells the browser what your original code looked like.
Chrome and other browsers will automatically load and parse this file when you open your developer tools. Then, you'll be able to see the original source code (and in the original language, for anything transpiled) and debug it as if it were not bundled in the first place.
Don't deploy this map file, unless you want external users to be able to see all your original source code.
I've launched a redesign of our website and I'm using quite a bit of Javascript for the first time.
I've learned that I should be combining all my javascript and css into one file (each obviously) but while I know I can combine the css without problems but the javascript I'm not sure of.
I have to load:
jquery.min.js <-- I load the top two from ajax.googleapis.com, is that a good idea
jquery-ui.min.js
javascript for Facebook
some for google plus button
same for twitter
some for google analytics
then some inline stuff to hide divs which javascript users shouldn't see and that type of thing.
you can see it here: traditionalirishgifts.com
So can I just copy and paste the contents of all these files into one big file. Find some way to minify (haven't looked into that fully yet) it. Load this one file right at the bottom of my page before and bingo?
I'd use this tool: http://jscompress.com/
JSCompress.com is an online javascript compressor that allows you to
compress and minify your javascript files. Compressed javascript files
are ideal for production environments since they typically reduce the
size of the file by 30-90%. Most of the filesize reduction is achieved
by removing comments and extra whitespace characters that are not
needed by web browsers or visitors.
You should always be able to merge all your external JavaScripts into one file. You can use a server-side compressor to cache it and serve it as one file. It does put some constraints on the files, like which file should load first etc. Also, if there is a syntax error anywhere it will crash completely.
Keep in mind that 3rd party code like code from google can't be mixed in. Usually there is some kind of authentication going on (or an API key in the URL). If you try to cache that code, it will stop working after a while. So you do need to keep those separate.
I just finished my website, which I started 2 years ago. I was always trying new things, which sometimes included adding different frameworks or other external JS files.
Now I don't know which of the linked files/lines of JS are unused. Is there a tool which can detect these files and lines of code? It would save me a lot of time.
This answer offers Google's Closure Compiler which, in the process of minifying and concatenating your JavaScript code, can remove "dead code".
Quoting from the documentation for the compilation levels:
Compilation with ADVANCED_OPTIMIZATIONS removes code that is provably unreachable. This is especially useful in combination with large libraries. If you use only a few functions from a large library file, the compiler can remove everything except those functions from its output.
Also see this answer which contains more information on Google's Closure Compiler.
I had this need so I created a tool that detects unused JS on the browser side, not just from the sources, so it can also test third parties scripts.
It works by creating a local proxy on your computer that intercepts JavaScript requests and instruments these files on-the-fly. The tool is than able to detect which parts of the instrumented files have been used by the page, and which don't.
I made it open-source and you can find it here: https://github.com/gmetais/unusedjs.
For this answer, I am not sure whether it's helpful or not. How about trying Sonar. Sonar has a javascript plugin that can check your js code quality and list the code that unused.
I've been looking at a similar task for the past few weeks myself and ended up with the following powershell query:
PS> Get-ChildItem -Path C:\PathToProject\ -Filter *.as?x -Recurse
| select-string -pattern "src=""([^""]*.js)"""
| Select -Expand Matches | Foreach { $_.Groups[1].Value } | select -unique
First it recursively selects all .aspx and .ascx files in our project directory, then finds src attribute values that refer to .js files (presumably those of script elements) and traces distinct values - voila, you have a list of .js files as referenced in your project!
It would be fairly straightforward to adjust the query so that it fits your specific project and its structure. Make sure you don't iterate over outdated files that may include obsolete references. Account for markup discreptancies - could you have used single quotes for attribute values in the past, or left unnecessary whitespace around the "equals" symbol, or both? Could you be including these files programmatically or asynchronously from inside another js files? etc. etc.
In Google Chrome Developer tools, you can now view "Coverage" on the Sources tab to display unused Javascript and CSS by percentage of each file, or even on a line by line basis.
Here's the announcement of the feature in 2017.
Though it is pretty old question, this might help for this type of problem - https://github.com/skpaul/LocateMe
I wrote this to use in my project.
The documentation for tinymce notes that one can compress all the javascript and components (which I assume includes plugins) into a single file. They do note reasons why one might not want to that as well.
Compressing into a static file
It's also possible to simply concatenate the necessary components and some boilerplate code into a single .js file. However you will always have to recreate this file if you want to use other TinyMCE plugins, or you upgrade TinyMCE. You will also probably want to configure your webserver to compress javascript files.
But assuming one actually did want to do it, how does one actually go about it? Build.xml does does not provide an appropriate task it seems. At least when I tried it the plugins did not seem to be included when I loaded tiny_mce.js.
There are some really excellent command line tools for this, but you can also do this easily with just a text editor. The simplest way is to just open each file, copy the contents, and paste the contents into a single JS file ("everything-all-together.js", say). You'll need to make sure you paste the files into the single file in the same order you would've put the script tags into the HTML doc. Once you have all the files all together, you can use tools like JSXMin, YUI Compressor, or Google Closure. There are also some tools online that do this, like http://www.minifyjavascript.com/. You can paste in the uncompressed JS and copy back out the compressed JS. This makes the build process really cumbersome, but if you just need to do this once, that will get you there.
The best way to do this is to do it as a build step for the site. That means when you make changes to the JS files, you rebuild the compressed JS file to include the changes as well. This can be a cumbersome step if you're iterating quickly and changing files over and over again. You don't want to have to rebuild the compressed file with each save. You can solve this by setting up development and production modes of the site. When being loaded in development mode, the JS files aren't grouped together. When all the necessary changes are made, you'd rerun the build step to generate the single compressed JS file. To do the minification from the command line, you'd probably want to use Google Closure: https://developers.google.com/closure/compiler/. If you download the compiler app, you can do the following:
java -jar compiler.jar some-file.js some-other-file.js > compiled.js
That will generate a file called compiled.js that includes the contents of some-file.js and some-other-file.js in a minified format. You can specify as many files to compile as you need to. Actually, I'm selling Closure a bit short to say it's just minified. It's also extremely optimized code. Pretty much every site should be doing this to all of there JS all the time unless they're already doing something better.
I hope I'm getting you (and the tinymce docs) right, but this sounds a lot like combining JavaScript files on the server side. This means taking the contents of all of your JS files, putting them into one file and returning that one to the client.
Why would you do that? Well, this should be obvious, but.. you reduce the number of HTTP requests to your server, which is always a good thing.
How do you do that? There are many solutions out there for all server-side languages and frameworks, I suggest doing a Google search for "[your language] javascript minifier" or something similar.
Hope this helps.