add "namespace" to imported files

[tlindig]

I need to add a base class to all rules for imported resources.

I have a project that use bootstrap less files to build an own theme.

I need to "namespace" all rules, to ensure, that the css rules only match in a subtree of document tree.

I tried to wrap all imports with the a base class like this:

 .my-base {
    @import boostrap.less
    @import my.less
}

but than, the "Parent Selectors" with "Changing selector order" makes problems.

Example:

rule in imported less file:

.menu {
  border-radius: 5px;
  .no-borderradius & {
    border-radius: 0;
  }
}

output after wrapping:

.my-base .menu {
  border-radius: 5px;
}
.no-borderradius .my-base .menu {
  border-radius: 0;
}

The second rule do not match anymore!

What I want as result is:

.my-base .menu {
  border-radius: 5px;
}
.my-base .no-borderradius .menu {
  border-radius: 0;
}

The only way I found is to run less two times and produce a temporary css file, that I import in second run like this:

 .my-base {
    @import (less) temp.css
}

But than I got wrong results for CSS calc function.

Input first run:

height: calc(~"100% - " 24px);

Result in temp.css:

height: calc(100% -  24px);

Result after wrapping:

height: calc(76%);

It would be nice, if there would be a way to handle this in one run.

May be with a special import option to prevent the "Changing selector order" of "Parent Selectors" to go outside an import
or a global option for less that it can add a base class to all css rules after regular processing.

[seven-phases-max]

Parent selectors are not the only problem of such Bootstrap usage (see #2052 (comment)).
Speaking of the particular parent selectors problem, I guess #1075 would be a better solution then (since it targets/provides the related functionality itself instead of trying to workaround issues with external/outer options as proposed here).

[tlindig]

Since version 2.x may be this problem could be resolved with a Plugin.
But where would be the right place to add it?

It would be some thing like postEvalVisitor or preToCSS. It could insert a new root node to the evaldRoot.

Or to handle a separate import may be it could be triggered after a import is evald.

[seven-phases-max]

Since version 2.x may be this problem could be resolved with a Plugin.

Which one? Yet again there're several unrelated problems with namespacing a library (a mentioned the issue with the the list above). And I can't see how a plugin can do anything about this... (could you elaborate?)

Speaking of the "calc problem" (I'm sorry I don't know why I did not comment that above), the solution is as simple as: just compile your "second pass" code with --strict-math=on.

[mathieumg]

👍

@seven-phases-max You seem to have added the support as plugin label a month ago, do you have any details to go along with that? Is there a plugin that does it, somewhere?

Edit: I ended up using https://github.com/ruslansavenok/postcss-wrap after the whole LESS is done compiling.

[seven-phases-max]

@mathieumg The label roughly means "the feature should not or cannot be implemented in the core, but can be supported via plugin".

[stale]

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.