minify
minify copied to clipboard
babel
Feature Request: Added max line length
This is a feature request for a max line length option. Uglify has a similar one available.
var options = {
code: true,
comments: true,
presets: [
['babel-preset-babili', { maxLineLength: 500 }]
]
};
I'm curious, there's another feature of Uglify that I personally would like to add at some point, because it tends to make debugging minified builds easier, which is setting semicolons: false. This means that rather than wrapping at a particular line length, uglify tries to use newlines instead of semicolons wherever possible.
This means that no extra bytes are added, but lines end up being relatively short most of the time.
Would this also achieve what you're looking for? Hard-wrapping at a line-length would either mean adding an extra byte at every newline, or require the logic to replace the closest eligible semicolon nearest the end of the line anyway.
Hello @loganfsmyth.
If I am understanding you correctly I would think adding a new line at every semicolon would add way more bytes rather than replacing a semi colon with a new line after a certain amount of characters. This would add maybe an extra couple bytes but it would be optional and a minimal impact on size.
The length would not have to be that exact number of characters but maybe an approximation.
My reasoning was based of something I read about minifed files and my experience with some text editors. I have experienced issues with viewing large single line files particularly in Atom. I also thought there was some sort of impact on large minified files in the browsers. Although I could be wrong on that fact. I will try and find the resource that I read. Even so aesthetically when viewing a minifed file I personally think it is nicer to see a couple lines. Most of the big minifers such as Uglify and Closure rap at a max length and or provide the option for wrapping at a certain length.
Update So I found that resource that I referenced. Why do we have newlines in minified JavaScript?. In summary it is reported that FireFox and Chrome can have issues when trying to serve single line files. And Closure has an faq which mentions firewalls having issues with single line files.
I don't mind trying to dig into the code for a PR. If this would be accepted if it passed all the test just point me in the right direction.
I would think adding a new line at every semicolon would add way more bytes rather than replacing a semi colon with a new line
Sorry, I should clarify I mean replacing every semicolon with a newline, as long as ASI rules would allow parsing still, avoiding extra bytes.
For wrapping lines, there are two primary implementations that come to mind, and it sounds like Uglify can do both:
- Insert a newline between tokens where they are allowed, ideally replacing space that would have been output anyway, to avoid extra bytes being added
- Insert a newline after every semicolon, ideally removing the semicolon for all cases where ASI can re-insert it, and maybe not bothering with newlines where they can't
Both achieve the goal of making the file not immediately crash editors that don't handle extra-wide columns.
Your proposal is 1. and I brought up 2. because to me it has the advantage that since it will encounter semicolons more often than it will hit an arbitrary line length, much more wrapping will happen and the code will be almost readable. It also means stack traces are less likely to end up being "line 2 column 500" which can still be a pain to debug.
I could also see a usecase for both, but I wanted to raise it as an alternative.
The implementation of "replace the first space after the max line length with a newline" would probably be extremely simple though, whereas semicolons and ASI are complicated, so it's not all roses either way :)
I'm a big fan of liberally adding newlines (in place of semicolons). I'm currently using babel+babili in a separate repo to build a minified script that's directly imported into my main repo. The current setup requires me to commit this minified file, which is currently a 100% replace each time for a rather large script, even if only one line changed in the original source.
If the minified file used newlines in place of semicolons, it should considerably cut down on the amount of data needed to be saved in each commit after an update.
I wouldn't expect that to change the amount of data. Git is still either going to create a whole new file, or put the content in a compressed pack file, and I'd expect git to compress either case fine since the content you changed is the same small section of the file whether there are newlines or not.
It would help from a diff-readability standpoint, just not the on-disk filesize.
It would help from a diff-readability standpoint, just not the on-disk filesize.
Yes, this is what I mean. Both the diff, and the amount of data committed. By rewriting the entire file every time, each commit is considerably larger. (Edit: Well, I learned something new today. Git is smarter than it appears. But yes, it would still be nice to have easier to consume diffs for debugging purposes.)
My point is, what is shown in the diff is just a diff, it is not tied to the amount of data that is committed into a repo. In Git, you are always committing a whole new file. It may compress it for you, but it will do it however it sees fit, which is likely unaffected by how nice the Diff looks, in this specific case.
Too bad the thread hasn't had any updates in so long. There are indeed cases where a wrap becomes mandatory. For example, if a Javascript program is translated by Babel and then inserted as static Javascript directly into an HTML file within a
