Imports reference broken

[AlistairB]

Hi,

I updated from (i think) .5 to .7 and imports > reference stopped working

        less: {
            prod: {
                options: {
                    paths: styleLocation,
                    imports: {
                        reference: ["mixins.less", "variables.less", "images.less"]
                    },
                    syncImport: true
                },
                files: [{
                    expand: true,
                    cwd: styleLocation,
                    src: ["**/*.less", "!container.less", "!variables.less", "!mixins.less", "!**/external/*.less"],
                    dest: styleLocation + "/temp",
                    ext: ".css"
                }]
            }
        },

I have changed imports > less to imports > reference. But it wont compile because it can't find mixins in mixins.less.

Any ideas? Any way I can get more information on what is happening?

[MarcDiethelm]

So it's not just me doing something wrong. :) Confirmed.

[jonschlinkert]

Strange, sorry I don't know how I missed this issue. wasn't intentional. I'll look into it!

[jonschlinkert]

I've been trying to debug this, but it's working fine for me. I have a hunch that it has something to do with self-referencing files. Have you both tried using the feature with just a couple of files? that will help me know where to focus

[MarcDiethelm]

That's weird then. I just did some testing and reduced my case down to just two minimal files. One for reference use containing a single mixin definition. And one 'regular' src file. No import statements in either file.

less: {
    ref: {
        options: {
            imports: {
                reference : ['<%=tcBase%>/css/lib/reference/test.less']
            }
        }
        ,src  : '<%=tcBase%>/css/lib/test.less'
        ,dest: '<%=destCss%>/ref.css'
    }
}

But Less doesn't know about the mixin and aborts. I tried it with relative and absolute paths.
Did you already try to debug this with a assemble-less installed via npm? Not that it makes much sense. But maybe there's some subtle difference.

[MarcDiethelm]

Aha! just wrote some garbage in the 'reference' file, but Less did not complain about that at all. Just about the missing mixing. Apparently the file is not being read at all.

[jonschlinkert]

It might be that the templates aren't being expanded. Yeah, I just pulled it down and started playing around with it from scratch. I also installed Bootstrap using bower, then I setup a task to compile each less file to a separate CSS file using imports.reference. It works fine until I get to utilities. I'm doing actual debugging now, but I have a cold so I'm not sure if I'll get it worked out today or not. sorry for the mess.

[MarcDiethelm]

Haha, well you did warn me that assemble-less is experimental in nature.

So you are reproducing the problem?

For me there's no urgency to get this fixed. If you can debug it sometime next week that's fine with me. Get well soon!

[jonschlinkert]

Yes, I did in fact reproduce the issue. one problem is that files added to any of the imports are not getting removed from the actual src files, I was counting on globbing patterns to help there. but it's just error prone. I've already completely reworked the logic and it's working great, it's a lot cleaner:

// Probably the biggest hit on task execution time.
var parseImports = function(options) {
  var directives = _.pairs(options.imports);
  var statement = '';

  directives.forEach(function(pair) {
    pair[1].map(function(filepath) {

      // Don't add a circular reference.
      if (!!~srcFile.search(filepath)) {
        return;
      }
      statement += '@import (' + pair[0] + ') "' + filepath + '";\n';
    });
  });
  return statement;
};

srcCode += parseImports(options);
srcCode += file.readFileSync(srcFile);

Now I'm refactoring how metadata works so that it doesn't mutate upstream values and cause unexpected issues in other grunt tasks! Yikes! I'm probably going to have to implement more rigid conventions around how data is defined. ... huh, actually I completely forgot that I created this lib until just now lol. I can use this to solve it.

I'll let you know when I have something...

and thank you! I appreciate it!

[jonschlinkert]

See: b8d41f6

This is the v0.8.0 branch, you'll have to pull it down with git or download manually to test it. let me know if it works for you. If there are problems unrelated to this one, please open new tickets for those.

[jonschlinkert]

also, if you set debug: true in the options, the task will generate some before/after files (.less and .json) into a tmp directory, so you can inspect what's happening.

[jonschlinkert]

@AlistairB / @MarcDiethelm ping. any feedback on v0.8.0? Just do this to install:

git clone -b "v0.8.0" https://github.com/assemble/assemble-less.git && cd assemble-less && npm i

[MarcDiethelm]

:) Today is the first day that I actually have time to test it. So I just opened this issue again to check out your instructions for testing and I find your new comment...

It's working! Albeit there's another issue:

• The path is not being expanded (globbing doesn't work)

 paths: ['<%=assetBase%>/css/lib/reference']
,imports: {
    reference : ['*.less'] // no worky
}

---

FYI: I initially constructed the path myself:

reference: [path.relative(srcAbsolute, '<%=assetBase%>/css/lib/reference')+'/helpers.less']

That's probably quite a bit more efficient than using paths, especially for big projects that specify a lot of imports? What's your take on this?

[jonschlinkert]

Yeah I think I mentioned in the commit messages that I intentionally took that out, because it increases build time and it's just brittle. Even if you only reference files one folder deep (e.g. *.less) every loop will scan every one of those files. I can see it being useful though, I guess I can look at re-implementing it if necessary

[MarcDiethelm]

Mmh yes, for me it's a prerequisite to using it. I don't want users to have to configure Grunt, instead they can use folders to drop their assets into, like the reference folder in my example. Of course globbing can be abused (not just in this instance), but most users will never actually need to use @import (reference) anyway. Those who do should know what they're doing.