New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache parsed imports for faster and incremental build #2746

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@slorber

slorber commented Dec 3, 2015

This is related to this discussion:
#2640

I propose an experimental option to use imports caching.

This is experimental because it is insecure regarding to @import (multiple) according to @seven-phases-max

However, for most less users, this setting will be enough secure to leverage better productivity in a development environment.
Because many don't use @import (multiple) it would be a bad to not benefits from these perf gains just for features we don't always use.

If the user does not use these options then nothing would change for him. I recommend only using this in a dev mode setting (why the option!)

New render options

render can be called with options:

  • withImportsCaching: true => Means that the caching will kick in

The cache, by default, will be empty at the beginning of a render, so that modified files between 2 renders will always be reloaded. However this simple trick divides the compilation time by 2 on my app and someone else too.

  • withManualImportsCachingInvalidation: true => means that the client will manage himself the evictions from the cache
    With this additional option, the next compilations will be faster because the cache will already be filled, and compilation time is divided by 3.

However the user has to call less.invalidateImportsCacheFile himself everytime a less file change.

This could probably be simpler to use if less supported some kind of watch mode (like watchify for browserify)

Exemple gulp integration

        gulp.watch('./src/**/*.less').on('change', function(file) {
            less.invalidateImportsCacheFile(file.path);
            gulp.run('styles');
        });
var isProd = process.env.NODE_ENV === 'production';

function compileLess() {
    return less({
        withImportsCaching: !isProd,
        withManualImportsCachingInvalidation: !isProd
    });
};


gulp.task('styles', function () {
    return gulp.src("./src/app.less")
        .on('error', handleErrors)
        .pipe(compileLess())
        .on('error', handleErrors)
        .pipe(gulp.dest('./build'))
        .on('error', handleErrors)
        .pipe(gulpif(!isProd, livereload()));
});
@royriojas

This comment has been minimized.

royriojas commented Dec 3, 2015

it will be awesome that apart from providing the option to use the cache, then this cache could be persisted, that way we can make incremental builds possible with ease, like in the case of persistify

@matthew-dean

This comment has been minimized.

Member

matthew-dean commented Mar 15, 2016

I'm not a huge fan of these long option parameter names (withManualImportsCachingInvalidation). Feels more like Java / Objective-C options than JS.

What were @seven-phases-max's security concerns?

@stale

This comment has been minimized.

stale bot commented Nov 14, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment