I am curious if there is a full minifier that can do javascript AND the php / html minification? As a for instance, if you look at this pen:
http://codepen.io/ajhalls/pen/qmEKVY
You can see in the HTML area you have the code
<div class="col-sm-1 svgPatternItem " data-id="svgPattern-42 " style="font-size:14px;text-shadow: 0px 0px 4px rgb(0, 0, 0);color:#fff;position:relative;width:100px;height:100px; ">
Then in the javascript, you have:
$(".svgPatternItem").each(function( index ) {
while the class svgPatternItem makes it descriptive and readable, it is unnecessarily long. In sublime I could do a global search and replace to make that class aa, and the next one class ab and so on, but that is exactly the type of work you would expect a macro to excel at, yet I haven't found one that will modify both.
To further complicate matters, I have mixed in some new ECMAScript 2017 that breaks most minifiers, but which made development so much more pleasant like using the backtick when defining multiline variables. I could revert things to previous JS if needed, but it makes it harder to develop on unless it is required.
I was looking at http://esprima.org and it seems that if you look at the online parser with the js code from the codepen earlier you would just need to look for the callee => arguments => value and if it was an alphanumeric value, do a global search and replace using a short variable name through the entire code base of php and javascript which "should" work.
All that being said, as evidenced from my last two questions, I haven't found a way to do that parsing myself using javascript or PHP. Maybe python could do it, but I wonder if I need a full windows application such as Sublime to do the work for me so am wondering if anyone else has solved this particular issue.
As far as JavaScript minification is concerned the best is Google Closure Compiler.
It has an online version as well as a downloadable runnable java jar file.
Know more about Google Closure compiler for JS here:
https://closure-compiler.appspot.com/home
https://developers.google.com/closure/compiler/
HTML Minification:
There is a Repository at github that lets you CSS and JS and HTML into a single line of code, you can find it at https://github.com/searchturbine/phpwee-php-minifier
It runs on the PHP engine.
If you want to obfuscate your JS code there is a concept called uglification It basically minifies as well as obfuscates your code against reverse engineering upto a certain level find more about it at :https://github.com/mishoo/UglifyJS2
Related
I have seen a lot of websites with some function (p,a,c,k,e,d) in their JavaScript code. The different websites may have different bodies of this function, but they all use the same parameter names (p,a,c,k,e,d). Is it a standard or a library or something?
Secondly, it seems that this function is supposed to be executed as soon as the page loads. Like the following snippet from a website.
Can you help me in understanding this code? eval() is used to evaluate expressions like 2+3 but how is the following code passing a function to it?
try{
eval(
function(p,a,c,k,e,d)
{
//some code goes here
}
}catch(err){}
So if you use http://matthewfl.com/unPacker.html as I posted in the comments, it "unpacks" the code into this:
(function()
{
var b="some sample packed code";
function something(a)
{
alert(a)
}
something(b)
}
)();
It doesn't seem to be malicious. For a soft argument on why you would use this, see javascript packer versus minifier:
Packed is smaller but is slower.
And even harder to debug.
Most of the well known frameworks and plugins are only minified.
Packer does more then just rename vars and arguments, it actually maps
the source code using Base62 which then must be rebuilt on the client
side via eval() in order to be usable.
Side stepping the eval() is evil issues here, this can also create a
large amount of overhead on the client during page load when you start
packing larger JS libraries, like jQuery. This why only doing minify
on your production JS is recommend, since if you have enough code to
need to do packing or minify, you have enough code to make eval()
choke the client during page load.
Minifier only removes unnecessary things like white space characters
where as a Packer goes one step further and does whatever it can do to
minimize the size of javascript. For example it renames variables to
smaller names.
It's a function which decompresses compressed/obfuscated javascript code. Many JS libraries and scripts make use of it.
There are online tools where you can pack and unpack code via the browser, which use the function.
As I have seen that eval(function(p,a,c,k,e,d){}) is used in http://www.indiabix.com which uses it for hiding whole contents when user get download the page and open it . Maybe that is the inner workings of the particular code.
I've made a simple programming language and compiler using Flex and Yacc, and I want to be able to convert my code for use in the browser.
I've already taken a look at projects like Jison, but I don't think that would work for me as I'd then have to maintain two different codebases.
Looking around some more, I'm pretty sure compiling my compiler to WebAssembly and running that in the browser would be the solution. Only problem is that I'm not sure how to go about doing that. Can the Flex library that I pass when linking the lexer and the parser together (-lfl) also be compiled along with my compiler?
I really have no experience with WASM and I'm pretty new to Flex/Yacc too, so there may be some very obvious solution, but I can't seem to find anything.
If you want to take a look at my code: https://github.com/inobulles/aqua-compiler/tree/master/langs/amber
Thanks alot for your time!
There is nothing of much use in -lfl; you shouldn't need it in any real application.
If you don't define yywrap() in your flex file, then add
%option noyywrap
to your flex prologue, so that flex doesn't put a reference to yywrap into the generated code. If you do define yywrap then you already don't need -lfl, but you still might think about %option noyywrap so that you don't need the definition.
I don't know how WASM deals with stdio.h functions; presumably, your intent is to use some other mechanism to feed text into your lexer, but the generated code will still contain references to standard library I/O functions (as does the code generated by Bison).
I'm trying to extend Monaco Editor to allow users to write in a hybrid of JavaScript and another language, using delimiters to separate them within the same file, similarly to how Markdown allows writing multiple languages using fenced code blocks.
The difference is that I want to keep all the other IDE features that Monaco has built in for JavaScript, such as linting (done via diagnostics), smart auto-completion, jump-to-definition, auto-formatting helpers, and every other IDE feature that comes with Monaco's built-in JavaScript mode. I'd like these features to still work within the JavaScript portion of the code that Monaco is editing, and be disabled for the sub-language portion.
My first attempt was to call setMonarchTokensProvider, passing in a modified version of TypeScript's tokenizer rules. Specifically, I was able to add the beginning-fence delimiter to the root rule and create a new rule for the sub-language in the same way the documentation for Monarch (Monaco's syntax highligher) describes, using #nextEmbedded. (For testing purposes, I've been hard-coding CSS as the embedded language.)
When I call setMonarchTokensProvider like this for the language "javascript", it completely ignores this syntax highlighting tokenizer, and colors the code-fences of CSS as invalid JavaScript, indicating that you cannot override the built-in JavaScript mode this way.
When I call setMonarchTokensProvider with a new language (e.g. "mylang") and set the editor to use that language, it provides correct syntax highlighting (!) for this CSS-in-JS hybrid language. But all other advanced features that were found in the JavaScript mode are no longer present. The editor didn't have any smart auto-completion for methods defined on classes in the same file, or any in-editor error-reporting for invalid syntax, or any of its trademark JavaScript IDE features.
So my next attempt was to modify the pre-bundled Monaco code's TypeScript definition to include my custom syntax highlighting rules. This correctly highlighted my CSS-in-JS code completely (!), when setting the language to "typescript", and left all the other features intact (!) including diagnostics reporting (live-validation and underlining of errors), auto-completion, all of it! (I didn't try it with "javascript" but it's safe to assume it probably works or is trivial to get it working, since JavaScript is actually implemented as a variant configuration of the TypeScript mode in Monaco.)
Unfortunately, it also considered the entire CSS portion of it, including the fence around it, to be invalid JavaScript code.
I know that this is theoretically doable, because within HTML mode, you can embed CSS or JS with full support for proper validation and auto-completion and every other IDE feature; basically, every sub-language in an HTML file works like it's in its own file: HTML features in the root of the file, CSS features within style tags, JS features within script tags.
But digging into the TypeScript plugin's implementation inside Monaco, it's not clear where to begin editing this, either as a user of Monaco the library, or by forking it and patching it up where necessary. I started at trying to modify the DiagnostcsAdapter [sic] and tracing where it's actually implemented, but I got stuck two function-calls deep, where it seems to push a promise of syntax validation that returns a value that's used later, but the implementation of getSyntacticDiagnostics just shells the work out to some other implementation that I can't find anywhere else in the repo, nor in the monaco-languages repo or the vscode repo.
I make the similar thing. My solution is to place non-JS code inside a block comment:
regularJsCode()
/*
[your-syntax-identifying-start-token]
place any syntax you want here
[your-syntax-identifying-end-token]
*/
regularJsCode()
Then you can process it with your tools, parsers, IDE extension etc. And the coolest part you can make VSCode to syntax-highlight it like you want so it won't seem like some hack.
This approach is preferrable because your JS file still remains a 100% valid JS file.
If you still don't want to put your syntax into comments, then you should create your own file extension like .jsx/.tsx. In practical, VSCode terms this means you need to create VSCode extension with language server and stuff. This is not so easy, but the documentation is good. You could assemble your own JS highlighting code inside your VSCode extension using language server: https://github.com/sourcegraph/javascript-typescript-langserver
According to the creator of Monaco:
Architecturally, you can do the following:
use monaco-editor-core directly
define a new language to the editor
fork monaco-typescript and change it to work with your newly defined langauge id. Then, modify the TS language host code to not pass the original models to TypeScript, but first run a preprocess which strips your custom language out of the text, and then only passes on valid TypeScript to the TS compiler. One idea is to replace each character that you remove with a space. This will leave all the position/offset computation work without any effort on your side.
Good luck!
All the variables after minifications are defined just with one or two letters. Is there any tool or technique which can help finding the right variable I am looking for in the javascript code?
For example, I found google doodle soccer game: https://www.google.com/logos/2012/football-2012-hp.html and now I try to find the variable there the score or final score is saved. So I can make the highscore table for the game.
Any tip is welcome.
There is a nice tool called jsnice
What is JSNice?
JSNice is a new kind of statistical de-obfuscation and de-minification
engine for JavaScript. Given a JavaScript program, JSNice
automatically suggests new likely identifier names and types.
jsnice is different to other 'javascript beautifiers' in the fact it does not only formats the minified code, but is also predicts meaningful variable names.
Generally you want to avoid working with the minified source. Try to find the original uncompressed source with the full variables names.
I have never been able to successfully make changes to a minified Javascript file. My Javascript skills are pretty good but minifiers make it very difficult to work out what the code is actually doing.
Source Maps are newer thing that help solve this problem: http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/. But unfortunately in your case this will probably not work as Google has not provided a source map.
If you are forced to make changes to the minified source, try using some like http://jsbeautifier.org/ as #Mustafa_sabir suggested. Then try to figure out what each of the variables are. You could then either remember what they do or try renaming to something more meaningful.
Good Luck!
There is no way to recover Minified Javascript variable names unless the Javascript code or library have a map file to decode the original code in the Inpsector view of the browser.
In your example, It is not possible.
I am using Gwt 2.4. After compiling my project i am getting some document.write lines in the mymodle.chache.js which is most weired .
So i want to know the places which producing these lines in my GWT code and came across and found some lines of code like
element.setInnerHtml("blah ..blah..");
and
doc.write("blah..blah ..");
So i removed those line of code and compiled again again and still getting some (ex:document.write(df+er+t)) lines .
Anyone suggest a way to find the cause to producing those lines from my GWT ??
(assuming you're talking about the *.nocache.js file rather than the *.cache.* files, as *.cache.* don't contain calls to document.write, unless you're using a crappy third-party lib)
The *.nocache.js file is generated by the primary linker, so its content is independent from your code. It contains calls to document.write() for various things: determine your module base URL (as a last resort, when it cannot infer it from elsewhere), inject scripts and stylesheets referenced from your *.gwt.xml files, and finally inject the GWT application code itself (with the standard linker, this will be an <iframe>, with the newer xsiframe linker it'll be a <script>).
If you're really worried about it, it can be customized quite easily by extending the CrossSiteIframeLinker (xsiframe linker) and providing different code snippets.
Tip: compile with -style PRETTY to make the generated code readable.
You are not supposed to hand-edit/modify mymodle.cache.js. This file gets generated again from GWT Compiler. What issue are you trying to solve by hand-editing it?