duplicated properties when @importing multiple times (nested @import)

[vicb]

Master @imports A & B,
B @imports A

When using a mixin from A in the master file, the properties get duplicated

See the unit test for more info

Config: lessc cli version 1.0.21 on ubuntu 10.04

[cloudhead]

I guess the issue is that the file gets imported twice, that's the correct behaviour for mixins.

[jamesfoster]

Do you think it should import the file twice tho? If not it should also take into account relative urls. For example

// in main.less
@import: imports/import1.less;
@import: imports/import2.less;

// in imports/import1.less
@import: import2.less; // don't import this
@import: imports/import2.less; // do import this

[cloudhead]

hmmm, I wonder if there's an easier way to check if a file is equal to another file. Maybe something in the headers.

[jamesfoster]

File size is a cheap indicator and is most likely unique in any given set of source files. However it is possible to have 2 files with the same size.

Similarly with date modified.

If the server sets the ETag header you can / should use that.

We use the MD5 hash of the file contents as the key when caching but I personally think that's overkill.

[cloudhead]

hmmm, yea the problem is javascript doesn't have native MD5, or I would use that..
ETag would be ideal, but some servers don't set it. I'll have to think about this.

[vicb]

It seems that we agree that the files should not be imported twice. However is it always true ? (i.e. with the help of scope, importing in a mixim might be ok - cloudhead you can answer better than me on this one).

Many languages have already solved this issue in different ways:

• C -> #ifndef / #define / #endif
• PHP -> include_once()

The "C way" might be a bit harder to implement but conditionals might offer other great possibilities.

If the "PHP way" is chosen we need to choose a way to differentiate files. The absolute URL seems a good pick (we have it either directly or via document.location + relative URL) - I think it's better than size / length / MD5 because it does not consumes an HTTP request.
However it might not be enough: each URL maps to a single file but each file might be mapped to several URLs. In such case introducing a new keyword @@name: <unique name> might help.

The @import_once algo would then be: if the absolute URL has not already been imported, get the files anf check if the @@name as already been imported, if not import the file.

[jamesfoster]

I agree. within the context of a single request you should be able to assume that the resources dont change. so the absolute urls should be good enough.

checking for file changes is another matter.

[normanzb]

i think we should keep @import import multiple times because this is how original @import works,

i like @vicb's php-like solution, but instead of @import_once i like something better in 'comment' so it still compatible with original css syntax.

can we add something like this on the top of the .less file:
/!require:url(./abc.less)/

[NielsJanssen]

I am experiencing this problem as well. My project has a hierarchy of LESS files compiling into a single .css file. There is one utility LESS file which is included in several files, in the end result all mixins are duplicated the same amount of times as that utility file has been imported.

An @import_once, or perhaps @import: once url('url'); would solve this problem.

[divyanshu]

We are facing the same issue as @NielsJanssen on our project, any idea by when this issue will be fixed??

[ianstormtaylor]

Also running into this issue. Anyone figure out a solution?

[honi]

Having the same issue here. Couldn't find a simple solution, just ended up re arranging the imports so that they don't get imported twice.

[ianstormtaylor]

I'd really suggest checking out Stylus if you use node.js. I used LESS for a while, got frustrated with its complete lack of development, switched to SASS and then finally to Stylus. It really nails the features, the syntax is optional (and I use a middle-ground), its very powerful, and TJ is a really responsive developer of it.

If you don't use node.js, you can still use Stylus with ruby and compiling on your machine. And if you don't like Stylus for any reason, SASS/SCSS is also a nice alternative and can be done the same way.

Long story short: LESS is no good in the long run.

[honi]

Very bad attitude man.

It's not necessary to post that bs in here. You could have sent it by mail or alike. You can't have such high standards like wanting a "really responsive developer" for something that is free to use.

[ianstormtaylor]

Absolutely not.

I would have loved that advice when I first found LESS so that I didn't waste weeks of my time getting used to it, and converting to it and from it when I eventually left. Granted I should have noticed it myself first, as there are more open issues than closed ones, and most of them haven't been responded to.

It's not about what standards I can or can't have. It's about providing a warning to people, when there are better alternatives.

So I stand by my "BS" and hope people find the warning helpful.