DIY server-side LESS file processing
LESS is a popular CSS preprocessor that adds the ability to use constants, inheritance, nested styles, and much more, which is so lacking in CSS. As soon as I met LESS, I realized that this is what I need. The only thing that saddened my joy is that the developers offer only two options for using it: embed a JavaScript file that prepares directly in the browser or use a special script (which should be executed on node.js) that processes LESS files.
I didn’t like the option to process LESS files on the client because for large LESS files this causes noticeable pauses when the page loads. If you use the LESS version of twitter bootstrap-a - the load increases for a few seconds, which is absolutely unacceptable.
The precompile version did not suit me because I had to “manually” run the preprocessor. I saw a program that automatically regenerates LESS files when they change, but it turned out to be paid and only for MacOS.
I also wanted LESS files to be processed on the fly at the request of the web server and, therefore, connected in the same way as css. This approach is devoid of all the disadvantages described above. However, in this case it is a bit more difficult to observe the errors in the LESS syntax of the files: they can be seen only in the logs of the processing server. However, errors in the LESS file syntax were extremely rare for me, so this did not become a problem.
')
Unfortunately, I did not find any LESS file processors in either Python or Java (the languages ​​I am developing). So I just wrote a small http server on node.js, which uses the code of the “official” processor LESS files and processes the files “on the fly”. With this approach, however, you have to redirect the distribution of less files to a separate server, which means you can not do without nginx. In principle, you can use other servers (for example, lighttpd), but nginx is closer to me and further I will consider all configuration examples for it.
I took the lessc script as a basis - a console processor of LESS files, modifying it slightly and saving all the launch parameters (allowing, for example, to compress the generated CSS). The source code of the server I wrote. It starts on port 1337 and treats any request as a relative path to the .less file that processes and returns.
Next, configure nginx so that all less files are processed on the received http server:
Everything! Now you can safely use LESS in your projects, without fear of loading and not causing the preprocessor manually. Just insert .less files like regular .css:
Process LESS file for each request on the combat server is certainly too expensive. Here we will be saved by the ability of nginx to cache the answers of servers behind it: in this case, the result of processing LESS files will be cached by nginx (on the file system) for a given period of time, for example, 30 seconds. Once every 30 seconds to process LESS files will not load the system, and 30 second delays when updating a file with styles are usually quite acceptable (if you prefer, you can choose a smaller cache storage time).
The nginx configuration will change as follows:
Let us now consider briefly, step by step, what needs to be done in order to deploy this:
I didn’t like the option to process LESS files on the client because for large LESS files this causes noticeable pauses when the page loads. If you use the LESS version of twitter bootstrap-a - the load increases for a few seconds, which is absolutely unacceptable.
The precompile version did not suit me because I had to “manually” run the preprocessor. I saw a program that automatically regenerates LESS files when they change, but it turned out to be paid and only for MacOS.
I also wanted LESS files to be processed on the fly at the request of the web server and, therefore, connected in the same way as css. This approach is devoid of all the disadvantages described above. However, in this case it is a bit more difficult to observe the errors in the LESS syntax of the files: they can be seen only in the logs of the processing server. However, errors in the LESS file syntax were extremely rare for me, so this did not become a problem.
')
Decision
Unfortunately, I did not find any LESS file processors in either Python or Java (the languages ​​I am developing). So I just wrote a small http server on node.js, which uses the code of the “official” processor LESS files and processes the files “on the fly”. With this approach, however, you have to redirect the distribution of less files to a separate server, which means you can not do without nginx. In principle, you can use other servers (for example, lighttpd), but nginx is closer to me and further I will consider all configuration examples for it.
I took the lessc script as a basis - a console processor of LESS files, modifying it slightly and saving all the launch parameters (allowing, for example, to compress the generated CSS). The source code of the server I wrote. It starts on port 1337 and treats any request as a relative path to the .less file that processes and returns.
Next, configure nginx so that all less files are processed on the received http server:
location ~ \.less$ { proxy_path http://127.0.0.1:1337; } Everything! Now you can safely use LESS in your projects, without fear of loading and not causing the preprocessor manually. Just insert .less files like regular .css:
<link rel="stylesheet" type="text/css" href="bootstrap.less"> Caching
Process LESS file for each request on the combat server is certainly too expensive. Here we will be saved by the ability of nginx to cache the answers of servers behind it: in this case, the result of processing LESS files will be cached by nginx (on the file system) for a given period of time, for example, 30 seconds. Once every 30 seconds to process LESS files will not load the system, and 30 second delays when updating a file with styles are usually quite acceptable (if you prefer, you can choose a smaller cache storage time).
The nginx configuration will change as follows:
# , + # : http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=microcache:5m max_size=1000m; server { # ... # location ~ \.less$ { # .less proxy_cache microcache; # ( microcache) .less proxy_cache_valid 200 30s; # 200 () 30 proxy_pass http://127.0.0.1:1337; # http- } } Step-by-step instruction
Let us now consider briefly, step by step, what needs to be done in order to deploy this:
- Install node.js. On Linux - we put from repositories, on poppy and wines we put from offsite
- Install (if not used yet) nginx and configure it to distribute your site.
- Download gessub source LESS processor
- We take the source code of the http server and put it in the downloaded folder with the LESS processor in the bin folder
- Being in the bin directory in the LESS sources, we start the http-server with the command
node lessserv --path=/path/to/project/root
After --path = go to the root of your project, from where .less files will be distributed. All errors in the processing will be displayed in the console. - Redirect all requests to .less files via a running http server
location ~ \.less$ { proxy_path http://127.0.0.1:1337; } - On the battle server, enable caching for the results of processing .less files
Links
Source: https://habr.com/ru/post/138103/
All Articles