stravant / luaminify Goto Github PK

Okay, I swear, this time, I found a real issue, and I'm not just ranting about how simple it seems but how hard actually it is to reconstruct the input string from the output of LexLua.

Feeding this into LexLua, I get this:

Surely it's a bug. The two comments are supposed to be separate. And they are in the input string, with whitespace between them. But the comments appear joined together in the list of tokens, and the whitespace between/after them is out of order.

This goes with #18/#19. Lots of whitespace/comment bugs here.

On linux the file system is case sensitive. This makes line 11 in ParseLua.lua break. To fix this, change require ('Strict') to require ('strict')

given:
local a = {} local _ = a[ [[foo]]]

The source code will clump the brackets together to form [[[foo]]] (a syntax error) instead of [ [[foo]]]

when minifying, 1 of the 10's of times I've minified, I got an error. Seems like it may have been due to a protected keyword used as a variable name.

2022-01-20 14:26 Error: or '...' expected near 'do'

SleepManager.getCanSleep = Utils.overwrittenFunction(SleepManager.getCanSleep, function(sleepManager)
    return false
end)

SleepManager.getCanSleep=Utils.overwrittenFunction(SleepManager.getCanSleep,function(do)return false end)

local j,k=1,2 repeat local k=3 print(j) j=j+1 until j>k

prints 1 and 2 instead of 1 to 3 when minified

Hi, I think your project misses a license. Could you add one so it can safely be reused by others?

Currently, LexLua returns a large list full of tokens, each token potentially containing more lists of tokens, for example LeadingWhite full of more tokens that have to be plucked out manually and all sorts of weird things like that. Additionally, the order of LeadingWhite cannot be relied on by index (not even reversed), as I figured out earlier (see issue #18). Also, comments are preserved incorrectly in LeadingWhite (#20).

I'm looking to get a list containing tokens in the order they are encountered. That means by looping through the list and adding up the Data of each token, I'll be able to reconstruct the original input string passed to LexLua exactly.

Is there a ready-made function to create that list for me? If not, how would I create such a function?

There is a single space before the return, but it is not returned in the LexLua output. Newlines seem to be counted, though.

In some cases

for i = #ops, 1, -1 do

is minified to

for i = #i, 1, -1 do

Which causes issues for obvious reasons.

_ENV:

• Is a local in the top level scope
• Should never be renamed

I've hackily fixed this, but I imagine someone who knows the structure of the code can probably do better.

https://github.com/TomSputz/LuaMinify/blob/master/Scope.lua#L179

Perhaps an argument -r, for example, can be passed to the shell/batch commands taking a directory in which to recursively minify every lua file in each subdirectory? This would be really convenient.

You could do this by piping to find

I was using Minify.lua to make a in game linter, but for some reason, it doesn't detect ends on different lines.
So basically, it will underline my for loop as "expecting end" but in reality there is an end, its just on another line. I have no idea how to fix this, so, yea.

Thanks for this great tool.

Would it be possible to tweak it, or add an option, so that instead of writing the output to a file, it can be printed to standard output? E.g.

source.lua:

a = 1; b = 2

$ lua CommandLineMinify.lua source.lua
a=1;b=2

Possibly when the second argument is omitted, you could just write it to stdout instead of to a file with the same name as the input file, suffixed with _min. Or if you prefer you could add an extra argument / flag for this behavior.

Similarly, it would be useful to have the option to pass a Lua string to the program instead of a file name. Maybe something like:

$ lua CommandLineMinify.lua -e 'a = 1; b = 2'
a=1;b=2

…But perhaps I should file a separate issue for that :)

Keep up the great work!

Currently, LuaMinify simply maintains all parentheses in the original code to avoid having to deal with operator precedence.

However, if LuaMinify implemented operator precedence, more fine-grained minification would be possible.

For example:

-- this code:
a = ((1 + 2) - 3) * (4 / (5 ^ 6))
-- can be minified into:
a=(1+2-3)*4/5^6
-- but LuaMinify actually returns:
a=( (1 +2)-3)* (4 / (5 ^6))

Implementing operator precedence is fairly straightforward. Feel free to take a look at how I did it in my Lua minifier in JavaScript: https://github.com/mathiasbynens/luamin/blob/8c256798cb11a3087df857e9956e09b46396b33d/luamin.js#L26-L37 and https://github.com/mathiasbynens/luamin/blob/8c256798cb11a3087df857e9956e09b46396b33d/luamin.js#L176-L192

unpack{}==nil show up as unpack({}==nil) instead of (unpack{})==nil in AST

lua -e 'require"ParseLua"local j,k=ParseLua("print(unpack{}==nil)")print
(PrintTable(k))'