Skip to content

feature: Add compiler directives for deprecation warnings #2875

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nerdgore opened this issue Apr 19, 2016 · 3 comments
Closed

feature: Add compiler directives for deprecation warnings #2875

nerdgore opened this issue Apr 19, 2016 · 3 comments

Comments

@nerdgore
Copy link

nerdgore commented Apr 19, 2016

As less frameworks get older and larger there is a need to mark parts of your css as deprecated, making the move to a new version of the framework easier.

Consider the removal or renaming of a selector:

.u-align-left {
  @deprecate(.u-alignment-left)
  text-align: left;
}
.u-alignment-left {
  float: left;
}

The compiler could output something along the lines:

.u-align-left: This selector is deprecated and will be removed, use .u-alignment-left instead

This may be related to #1459 as a specific use case. However, personally I feel that deprecation should be handled on the compiler level.

@seven-phases-max
Copy link
Member

seven-phases-max commented Apr 20, 2016

Instead of too specific "deprecation message" function, it has to be a generic "whatever you set message" debug/log/warning function. I.e. exactly like in #1459. In fact there's no difference in the "compiler level" between directive and function, both are handled at the same compiler level. Now the only question if this should in the core or in a plugin (yet at least).
In a plugin, one can implement it either as a directive or a function (as soon as current master with "root functions feature" in is released), though personally I'll strongly object against @directive (first Less does not use @ for anything except variables just historically, second there are reasonable arguments against such "pseudo-CSS compatible stuff").

@seven-phases-max
Copy link
Member

I don't see any reason to not merge this into #1459.

@nerdgore
Copy link
Author

True, closing this in favour of #1459

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants