Fixing import by reference

[SomMeri]

• refactored how import reference works
• refactored to-css-visitor (this is side product, it was getting complicated)
• fixes issues Extend within (reference) imported files. #1851, Namespace imported less code does not get properly referenced, when there's a (reference) keyword. #1896, Extend from @import (reference)  #1878, A file imported by reference and then normally  #2716, When using an @import (reference), mixins that contain an & selector get added to the compiled output improperly #1968, Cannot put import by reference inside of a mixin #2162 (similar to Namespace imported less code does not get properly referenced, when there's a (reference) keyword. #1896)

[matthew-dean]

Wow, nice work!

[seven-phases-max]

👍

[SomMeri]

@matthew-dean @seven-phases-max Thank you. This took more then one attempt to get it fully (I hope) working.

If nobody objects, I am going to merge it in sometimes next week.

[SomMeri]

This comment describes how changes in pull requests are supposed to work.

---- Relevant less.js workflow before changes (this is visible in transform-tree.js):

Phase 1: eval - solves imports, mixins calls and detached rulesets calls

• imports are replaced by parsed files
• mixin calls are replaced by content of mixin definitions
• detached rulesets calls are replaced by contents called rulesets

Phase 2: JoinSelectorVisitor - joins selectors (paths) in nested rulesets with selectors in their parents

Phase 3: ExtendVisitor - process all extends

Phase 4: ToCSSVisitor - each visitX function in ToCSSVisitor is responsible for returning its own css equivalent.

• removes nested rulesets from their parents
• removes what should be invisible

The end result should be valid css tree which is then converted into text.

-------- New properties:
node.js has two new properties:

• nodeVisible - boolean returned by isVisible function
• visibilityBlocks - counter which can be raised by one or lowered by one through add and remove functions

Visibility blocks are placed on nodes imported by reference. Blocks are NOT placed on their childs, only the root of imported tree has visibility block. Adding visibility block on node means: "this node is root of tree that replaced imported by reference" or alternatively "this node came from one more import by reference then its parent".

Property isVisible can return one of three values:

• true - the node is visible
• undefined or null - undefined visibility, assumed to be the same as its parents visibility
• false - the node must not be visible (not used in practice)

Note: isVisible matters only for selector up until we hit the phase 4. - ToCSSVisitor.

-------- New visibility evaluation
Phase 1: eval changes:

• Import by reference adds visibility block to roots of whatever is imported.
• Mixin call with visibility block on it must add a visibility block to everything it is replacing itself with. The block would be lost otherwise.
• Detached ruleset with visibility block on it adds a visibility block to everything it is replacing itself with. The block would be lost otherwise.

Phase 2: JoinSelectorVisitor (e.g. selectors in nested rulesets) - no change

New Phase 2.5: Starting from root of ast, everything up to first visibility block is marked as "visible". Nodes with visibility block and their child are left unmodified.

Important outcome: each selector and extends now knows whether it came from visible part of the tree or or from something hidden being import by reference.

Phase 3: ExtendVisitor

• Each newly created selector gets the same visibility as the extend who created it. Visible extends produce visible selectors and invisible extends produce invisible selectors. Important outcome: all selectors are extended and know whether they should be visible or not.

Phase 4: ToCSSVisitor - In addition to generating its own css equivalent, each visitX function is now also responsible for setting replacements isVisible value to either:

• true - show me even if parent is hidden behind visibility block (e.g. I or something inside me came from extend),
• undefined or null - show me only if the parent is not hidden behind visibility block
• Note: if the node thinks it should not be shown at all, then it removes itself.

New visitX methods logic:

• Each simple node (such as rule, comment, anonymous, import etc) first checks whether it has visibility block. If the block is set, the node removes itself from the tree. Visibility property remains undefined.
• Rulesets: each ruleset removes all invisible selectors. If the ruleset ends up without visible selectors, then it is removed. If some selector stays, visibility is set on true.
• Directives and media: directive and media with visibility blocks on them still can be shown if something inside them was extended. Therefore they need to compile their bodies first to see what shows up. E.g. each directive with visibility block:
  • Compiles body.
  • Removes everything that does not have isVisible set on true explictly
  • If something stays in after that, directive visibility is set on true. Otherwise directive is removed.

[matthew-dean]

Just curious, does this alter the structure of the AST in any significant way? I was going to start work on a postcss-less plugin that would convert the Less AST into PostCSS nodes so that you could use less in a PostCSS pipeline.

[matthew-dean]

Also, I know that @lukeapage is working on refactoring the Less lib into ES6 + Babel, so with all that refactoring, might be good to coordinate.

[matthew-dean]

One more thing, this might be a good opportunity to clean up our PRs at the same time and either merge or reject.

[SomMeri]

@matthew-dean It does not alter structure at all, just adds two new properties to Node object.

[matthew-dean]

@SomMeri 👍

[SomMeri]

I merged the pull request in.