Hoisting (variables, functions, ...)?

[jasonkuhrt]

I would like to be able to disregard source order.

Abstractly:

// hoo.styl
a = b

b = d(foo)

// too.styl
d(zoo)
  bar zoo

// c.styl
@import too
@import hoo

This feature request... In demos appears useless. In small apps is welcomed but unneeded. In medium apps begins to be really handy. In large apps becomes a way to avoid all sorts of problems, and focus on the meaning of code (for example ordering code via high-level to low-level is only possible with hoisting, etc.)

I have been using less (driven by project owners) on a large project and have found that hoisting (and bubbling @media) are huge, huge wins.

Can/does this issue hold for mixins and extends?

[jasonkuhrt]

@kizu Agreed that hoisting is a huge win or no?

[kizu]

I need to think a bit more on this :)

[jasonkuhrt]

@kizu related, namespace support which would make hoisting that much safer

// geo.styl
rect(x,y=x)
  width x
  height y

// geo mixins are now available ANYWHERE via shape.*
@import "./geo" into shape

.some-selector
  shape.rect 5px

if a user doesn't want namespacing:

// geo mixins are now available ANYWHERE
@import "./geo"

.some-selector
  rect 5px

[jasonkuhrt]

@kizu poke. New thoughts?

[kizu]

While this could be useful, I'm afraid this won't be trivial to implement. @Panya could tell more about it :) Also, such change could potentially break stuff for people, so we couldn't do this unless 1.0.0, but if this would need a lot of efforts to implement, we'll need to weight it on the scales with some other features.

Overall, I'd say, the chances of implementing this are low.

[jasonkuhrt]

Alright, thanks for the update.

[alphapapa]

This would be a very helpful feature. I have a relatively simple project set up, but I just wasted a long time trying to figure out why some values were missing even though the files in which they were defined were being required. I eventually tracked it down to the order of the requires.

As a result, rather than having a simple, hierarchical require tree in which one file could be required which would then require all the others, I had to split up the requires to get them done in the right order, spreading them out among different files, which is not as straightforward.

Since Stylus is effectively a kind of compiler, it would make a lot more sense to have a single, global namespace in which all imports/requires are placed before evaluating their contents. Or, at least, all of the imports/requires at each level of scope should be parsed before evaluating each one of their contents. It would eliminate a huge source of bugs and save hours of frustration.