Summary

Upgrade lesscss to 1.7.5.

Review Request #6558 — Created Nov. 5, 2014 and submitted Nov. 7, 2014, 9:46 p.m.

Information

Owner

chipx86

Repository

Review Board

Branch

release-2.0.x

Bugs

Depends On

Commit

4aed8a3...

Reviewers

Groups

reviewboard

People

Description

During Review Board 2.0 development, we upgraded to less 1.5.1, which
had some changes we provided to them needed for our extension support.
Many improvements have since gone in that we'd like to take advantage
of.

This change bumps us up to 1.7.5. This is backwards-compatible with
1.5.1, and shouldn't negatively impact any extensions or the site.

Testing Done

Played around with all the major parts of the site. Didn't see any

problems at all.
Built static media for a release. All looked fine.
Built some extensions using less and RB's option settings. It all

worked fine.

Issues

Description	From	Last Updated
Can we use a non-minified version here for debuggability?	david	Nov. 7, 2014, 12:53 a.m.

Tool: Pyflakes
Ignored Files:
    reviewboard/static/lib/js/less-1.5.1.min.js
    reviewboard/templates/js/pipeline.html
    reviewboard/static/lib/js/less-1.7.5.min.js



Tool: PEP8 Style Checker
Ignored Files:
    reviewboard/static/lib/js/less-1.5.1.min.js
    reviewboard/templates/js/pipeline.html
    reviewboard/static/lib/js/less-1.7.5.min.js

reviewboard/static/lib/js/less-1.7.5.min.js (Diff revision 1)

The issue has been dropped. Show all issues

Can we use a non-minified version here for debuggability?

chipx86 Nov. 5, 2014, 1 a.m.

We can, but we've never needed it before that I know, and it's just more content to deal with (3x the size). Are you expecting we'll need that?

david Nov. 5, 2014, 1:07 a.m.

I guess for this it doesn't really matter. That said, I can't really hurt that much because it's all on the devserver (no real transmission times) and we don't really care about disk space.

chipx86 Nov. 5, 2014, 1:11 a.m.

True, it doesn't really have a real impact on the dev server. The only concern I have is that it's extra weight (~200KB) for the package, since we do distribute it (in case DEBUG=True).

david Nov. 5, 2014, 1:15 a.m.

Can we use pipeline to compile that for the packaged version?

chipx86 Nov. 5, 2014, 1:29 a.m.

We can do that (and I just implemented and tested it), but we still have to ship all source files so that static lookups work for pipeline.
When pipelining, we end up shipping the original source version, a stamped source version, and then the minified bundle. Right now, we don't use a bundle for this, so we only ship the two original versions, for a total combined size of 206KB (or 64KB compressed, for the package download).
With a move to pipelining and shipping the unminified version, we end up with a combined size of 852KB (or 183KB compressed, for the package download).

chipx86 Nov. 5, 2014, 1:30 a.m.

Sorry, numbers messed up there. Pipelined version is 671KB, compressed 153KB.

david Nov. 6, 2014, 12:43 p.m.
```
Alternatively, is there a source map?
```
chipx86 Nov. 7, 2014, 12:28 a.m.
```
Not that I see.
```

david Nov. 7, 2014, 12:31 a.m.

OK. For this I don't particularly care, but I definitely want to use either non-minified copies or have source maps for other things like jquery and backbone.

chipx86 Nov. 7, 2014, 12:32 a.m.

Yeah, I'm good with that. Source maps are a good way to go because we can safely strip those from packages.

Status:: Completed

Status:: Re-opened

Status:: Completed