postcss-extend - npm Package Compare versions

Comparing version 1.0.0 to 1.0.1

CHANGELOG.md

 # Changelog
 
+## v1.0.1
+- [Updated readme and exports, minor fixes](https://github.com/travco/postcss-extend/releases/tag/v1.0.1)
+
 ## v1.0.0
@@ -4,0 +7,0 @@ - [Updated to PostCSS 5](https://github.com/travco/postcss-extend/releases/tag/v1.0.0)

index.js

@@ -6,3 +6,3 @@ 'use strict';
 
-module.exports = postcss.plugin('postcss-simple-extend', function simpleExtend() {
+module.exports = postcss.plugin('postcss-extend', function extend() {
 
@@ -365,6 +365,14 @@ return function(css, result) {
       if (!isAntiPatternCSS && css.index(atRule.parent) < css.index(targetNode)) {
-        //throw this error only once, and only if it's an antipattern
-        // /*DEBUG*/ appendout('./test/debugout.txt', '\nANTIPATTERN CSS detected node :\n' + atRule.parent);
-        result.warn('@extend is being used in an anti-pattern (extending things not yet defined). This is your first and final warning', {node: atRule});
-        isAntiPatternCSS = true;
+        // Throw this error only once, and only if it's an antipattern
+        // Make sure index could be obtained for atRule parent
+        if (css.index(atRule.parent) !== -1) {
+          // /*DEBUG*/ appendout('./test/debugout.txt', '\nANTIPATTERN CSS detected parent at: ' + css.index(atRule.parent) + ' target at: ' + css.index(targetNode) + ' parent :\n' + atRule.parent);
+          result.warn('@extend is being used in an anti-pattern (extending things not yet defined). This is your first and final warning', {node: atRule});
+          isAntiPatternCSS = true;
+        // If index couldn't be obtained on atRule, check up the chain a step
+        } else if (css.index(atRule.parent.parent) !== -1 && css.index(atRule.parent.parent) < css.index(targetNode)) {
+          // /*DEBUG*/ appendout('./test/debugout.txt', '\nANTIPATTERN CSS detected parent\'s parent at: ' + css.index(atRule.parent.parent) + ' target at: ' + css.index(targetNode) + ' parent :\n' + atRule.parent);
+          result.warn('@extend is being used in an anti-pattern (extending things not yet defined). This is your first and final warning', {node: atRule});
+          isAntiPatternCSS = true;
+        }
       }
@@ -371,0 +379,0 @@ if (recursableRule.bool) {

package.json

@@ -8,3 +8,3 @@ {
   "license": "MIT",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "description": "As close to cssnext @extend as possible for PostCSS",
@@ -11,0 +11,0 @@ "homepage": "https://github.com/travco/postcss-extend",

README.md

 # postcss-extend [![Build Status](https://travis-ci.org/travco/postcss-extend.svg?branch=master)](https://travis-ci.org/travco/postcss-extend)
 
-**A [PostCSS](https://github.com/postcss/postcss) plugin that trys to minimize the number of repeat-selectors and rules you write in CSS.**
+**A [PostCSS](https://github.com/postcss/postcss) plugin that tries to minimize the number of repeat selectors and rules you write in CSS.**
 
@@ -8,5 +8,5 @@
 Use this plugin to:
-- Define an 'silent' extendable selector — a "placeholder selector" — to which you can (from anywhere in the doc), add concrete selectors from other rule sets.
+- Define a "silent" extendable selector — a "placeholder selector" — to which you can (from anywhere in the doc) add concrete selectors from other rule sets.
 - Add concrete selectors from one rule (containing the `@extend`) to all rule sets with the selector specified (or a subclass of the one specified).
-- Pull-in declarations in rulesets (most) anywhere in the doc (by a selector) from within `@media` statements (semi-safely)
+- Pull in declarations in rulesets (most) anywhere in the doc (by a selector) from within `@media` statements (semi-safely)
 - Extend existing media-conscious rulesets, even if some of them are within `@media` statements.
@@ -19,5 +19,5 @@
 
-The logical statement of *this* `@extend` is to 'allow my parent rule to use the declarations of what I extend'.
-The functionality is intended to somewhat-mirror Sass's `@extend` with `%` placeholders (a.k.a. "silent classes") and real rules.
-Unlike Sass's `@extend`, however, this plugin (among other things) *does not allow you to extend into selector sequences*: i.e. if you want to `@extend a`, it will not go off and try to extend: 
+The logical statement of *this* `@extend` is to "allow my parent rule to use the declarations of what I extend".
+The functionality is intended to somewhat mirror Sass's `@extend` with `%` placeholders (a.k.a. "silent classes") and real rules.
+Unlike Sass's `@extend`, however, this plugin (among other things) *does not allow you to extend into selector sequences*: i.e. if you want to `@extend a`, it will not go off and try to extend:
 ```css
@@ -35,3 +35,3 @@ #admin .tabbar a {
 
-It **will** however, try to extend selector sequences with the base-piece to work with, i.e. trying to `@extend .never` will match: 
+It **will** however, try to extend selector sequences with the base-piece to work with, i.e. trying to `@extend .never` will match:
 ```css
@@ -50,3 +50,3 @@ .never li:first {
 
-**`postcss-extend` is compatible with PostCSS v4.1+.**
+**`postcss-extend` is compatible with PostCSS v5.0+.**
 
@@ -81,3 +81,3 @@ > **A Note on "mixins" & "extends"**: Mixins copy declarations from an abstract definition into a concrete rule set. These `@extend`s (normally) clone a concrete rule set's selector(s) and add them to an abstract placeholder selector, or another existing rule. *This* plugin enables extends. If you would like to use mixins, as well — or instead — have a look at [`postcss-mixins`](https://github.com/postcss/postcss-mixins).
 
-You can also use it's aliases: `@define-extend` or `@extend-define`.
+You can also use its aliases: `@define-extend` or `@extend-define`.
 
@@ -96,5 +96,5 @@ ```css
 
-##### The '%' (silent) placeholder
+##### The "%" (silent) placeholder
 
-The '%' placeholder acts in exactly the same way as `@define-placeholder` and its aliases, with the three exceptions. One, that it doesn't need to be declared before it is extended. Two, you can extend out of it (thus extending anything that extends the placeholder, or nothing if the placeholder isn't referenced). Three, it needs to be specifically targeted in the extend, for example: `@extend %simple-list`.
+The "%" placeholder acts in exactly the same way as `@define-placeholder` and its aliases, with three exceptions. One, that it doesn't need to be declared before it is extended. Two, you can extend out of it (thus extending anything that extends the placeholder, or nothing if the placeholder isn't referenced). Three, it needs to be specifically targeted in the extend, for example: `@extend %simple-list`.
 
@@ -117,3 +117,3 @@ (`@define-placeholder`'s limitations are an originally unintended feature, kept for its possible usefulness as a stricter, more controlled method of extending).
 ```
-Both rules and placeholders are extended in much the same fashion, the only real difference is that placeholders can be named most anything, whereas rules need to be extended via the same syntax in the css. For example, to extend a 'foo' class it'd be `@extend .foo`
+Rules and placeholders are extended in much the same fashion; the only real difference is that placeholders can be named most anything, whereas rules need to be extended via the same syntax in the css. For example, to extend a 'foo' class it'd be `@extend .foo`
 
@@ -151,3 +151,3 @@ There is only one overarching `@extend` guideline to obey: `@extend` must **not** occur at the root level, it only can be used inside rule sets.
 
-You also can still specifically extend subclasses by-themselves by calling them out explictly.
+You also can still specifically extend subclasses by-themselves by calling them out explicitly.
 If (in the above example) you wanted to only get `background:brown` instead of everything having to do with `.potato`, you could just use `@extend .potato:first-child;`.
@@ -157,8 +157,8 @@
 
-The bridging behavior of this plugin is by far it's most dangerous, despite the steps to keep it relatively sane. Be mindful.
-The logical statement of *this* `@extend` is to 'allow my parent rule to use the declarations of what I extend'. Thus, when within an @media rule, it's behavior takes on the contingency of the rule, and instead of tacking on it's parent's selectors  to rules it extends (thus using their declarations), it directly brings in the declarations. 
+The bridging behavior of this plugin is by far its most dangerous, despite the steps to keep it relatively sane. Be mindful.
+The logical statement of *this* `@extend` is to "allow my parent rule to use the declarations of what I extend." Thus, when within an @media rule, its behavior takes on the contingency of the rule, and instead of tacking on its parent's selectors to rules it extends (thus using their declarations), it directly brings in the declarations.
 
-##### Simple declaration-pulling
+##### Simple declaration pulling
 
-Trying to extend a rule outside an `@media` from the inside is fairly straight-forward. For example:
+Trying to extend a rule outside an `@media` from the inside is fairly straightforward. For example:
 ```css
@@ -175,3 +175,3 @@ .potato {
   }
-  
+
   .spud {
@@ -196,3 +196,3 @@ @extend .potato;
   }
-  
+
   .spud {
@@ -206,3 +206,3 @@ color: red;
 ```
-Notice how `.spud` only takes in declarations it doesn't already have from `.potato`. Extending will never override declarations already present while copying. Additionally, notice how `.spud` extends `.potato`'s pseudo inside the media scope by tacking onto the target rule, just like before. That's because it is scope-conscious (especially while in an `@media`).
+Notice how `.spud` only takes in declarations from `.potato` that it doesn't already have. Extending will never override declarations already present while copying. Additionally, notice how `.spud` extends `.potato`'s pseudo-class (`:first`) inside the media scope by tacking onto the target rule, just like before. That's because it is scope-conscious (especially while in an `@media`).
 
@@ -218,3 +218,3 @@ ##### External Sub classes
 .potato:first, .potato ul:first-child {
-  float: center;
+  float: right;
 }
@@ -241,3 +241,3 @@
 .potato:first, .potato ul:first-child {
-  float: center;
+  float: right;
 }
@@ -252,3 +252,3 @@
   .spud ul:first-child {
-    float: center;
+    float: right;
   }
@@ -258,11 +258,11 @@
     background: purple;
-    float: center;
+    float: right;
   }
 }
 ```
-First let's notice that the sub class `.spud ul:first-child` (which wasn't within `@media` originally) is created with a copy of `.potato ul:first-child`'s declaration. Meanwhile, `.spud:first` was already within the `@media` rule, and it took on the extra declaration. If there is a rule within the `@media` with exactly the same selectors as what it would create, it will just pull in declarations. Keep in mind, the same ideas apply here while 'pulling in' declarations, it copies, but won't replace.
+First let's notice that the sub class `.spud ul:first-child` (which wasn't within `@media` originally) is created with a copy of `.potato ul:first-child`'s declaration. Meanwhile, `.spud:first` was already within the `@media` rule, and it took on the extra declaration. If there is a rule within the `@media` with exactly the same selectors as what it would create, it will just pull in declarations. Keep in mind, the same ideas apply here while "pulling in" declarations: it copies, but won't replace.
 
 ##### Extending something inside `@media` (on the outside looking in)
 
-So what if you want to extend something that's within an `@media` from the root. It's actually fairly straight-forward when you think about what that means. 
+So what if you want to extend something that's within an `@media` from the root? It's actually fairly straightforward when you think about what that means.
 ```css
@@ -302,11 +302,11 @@ @media (width > 600px) {
 ```
-Extending from the root, just like before just tacks on selectors onto target rules, even into the `@media`. This stays true to the logic of *this* version of `@extend` because it's maintaining the conditionality of the declarations within `@media`.
+Extending from the root, just like before, just tacks on selectors onto target rules, even into the `@media`. This stays true to the logic of *this* version of `@extend` because it's maintaining the conditionality of the declarations within `@media`.
 
 ##### Extending something in an `@media` while inside an `@media`
 
-**Don't**. It's currently directly-disallowed in code to prevent unexpected things from happening, and will throw an error to warn you. The current expectation is that the only time majority of users would do this is when making a mistake. That expectation remains unless someone can present a solution and a logical way of handling this (not in the native CSS parser) that is also a realistic common-use case.
+**Don't**. It's currently directly-disallowed in code to prevent unexpected things from happening, and will throw an error to warn you. The current expectation is that the only time the majority of users would do this is when making a mistake. That expectation remains unless someone can present a solution and a logical way of handling this (not in the native CSS parser) that is also a realistic common-use case.
 
 #### Chaining `@extend`s, or extension-recursion
 
-Definately one of the more powerful features of SASS's `@extend` is here too. It does however, come with a slight caveat that it is order-agnostic. Meaning that it doesn't enforce order by only extending that which came above it, it just goes.
+Definitely one of the more powerful features of SASS's `@extend` is here too. It does, however, come with a slight caveat that it is order-agnostic, meaning that it doesn't enforce order by only extending that which came above it. It just goes.
 ```css
@@ -346,5 +346,5 @@ .charlie {
 ```
-Doesn't that take a lot of computation to do though? Well, not really since it's not 'true' recursion. Since we're tacking-on selectors every rule is a living record of everything that has extended it, and if we're not tacking on selectors - we're copying everything we need from the other rule. Thus, in well-formed CSS we only need to go through the CSS doc once, top to bottom.
+Doesn't that take a lot of computation to do though? Well, not really since it's not "true" recursion. Since we're tacking on selectors, every rule is a living record of everything that has extended it, and if we're not tacking on selectors, we're copying everything we need from the other rule. Thus, in well-formed CSS we only need to go through the CSS doc once, top to bottom.
 
-In anti-pattern CSS (extending things yet to be declared), it will handle `@extend` recursively, but only if the extended target has unresolved `@extend` rules in it (thus, slowing down processing, but keeping it working as expected). As a bonus, there is a built in recursive-stack tracking that both detects infinite loops, and throws warnings (in order of least-tampered css first) for every step of the infinite loop. It also does its best to still process the CSS in the infinite loop (almost always as intended).
+In anti-pattern CSS (extending things yet to be declared), it will handle `@extend` recursively, but only if the extended target has unresolved `@extend` rules in it (thus, slowing down processing, but keeping it working as expected). As a bonus, there is a built-in recursive-stack tracking that both detects infinite loops, and throws warnings (in order of least-tampered css first) for every step of the infinite loop. It also does its best to still process the CSS in the infinite loop (almost always as intended).
 
@@ -374,17 +374,17 @@ ## Getting It Working with PostCSS
 ## Quirks
-As with any piece of code it's got a few quirks. Behaviors that are not intended, and not enforced, and may disappear (or be forcibly altered) with the next release, so it's useful to be aware of them.
+As with any piece of code, it's got a few quirks. Behaviors that are not intended, and not enforced, may disappear (or be forcibly altered) with the next release, so it's useful to be aware of them.
 
-**Order of Processing** : Currently, all of the `@extend`s being processed are run in a sequential manner from the top to the bottom of the doc. This keeps thing relatively snappy, but makes it so that we have to do conditional-recursion on not-yet-declared-or-extended rules. This leads to some blatant inefficiencies when processing badly formed CSS (anti-pattern CSS). So if you want to keep processing time down, write good CSS. If you're curious if what you're writing is an anti-pattern, don't worry, it will throw a warning.
+**Order of Processing** : Currently, all of the `@extend`s being processed are run in a sequential manner from the top to the bottom of the doc. This keeps things relatively snappy, but makes it so that we have to do conditional-recursion on not-yet-declared-or-extended rules. This leads to some blatant inefficiencies when processing badly formed CSS (anti-pattern CSS). So if you want to keep processing time down, write good CSS. If you're curious if what you're writing is an anti-pattern, don't worry, it will throw a warning.
 
-**Non-logical means of extension for `@media`** : As anyone who's aware of the complications discussed in the [SASS issue about extending across `@media`](https://github.com/sass/sass/issues/1050) would know. There is no way (known) of extending when `@media` rules are involved that is both 'clean and simple' and 'logically correct with how `@extend` is used elsewhere'. The way this plugin operates, and it's logical meaning, is a blatant compromise so that it has both common use cases and easier implementation. While the current implementations will not change (without flags), such things as extending an `@media` from within an `@media` does nothing, this could possibly change in the future. 
+**Non-logical means of extension for `@media`** : As anyone who's aware of the complications discussed in the [SASS issue about extending across `@media`](https://github.com/sass/sass/issues/1050) would know. There is no way (known) of extending when `@media` rules are involved that is both 'clean and simple' and 'logically correct with how `@extend` is used elsewhere'. The way this plugin operates, and its logical meaning, is a blatant compromise so that it has both common use cases and easier implementation. While the current implementations will not change (without flags), such things as extending an `@media` from within an `@media` does nothing, this could possibly change in the future.
 
 #### 'TLDR' Contention with the `@extend` [spec](https://tabatkins.github.io/specs/css-extend-rule):
 
-- **Order of Processing/Specificity** In normal cases, the document is processed top-to-bottom, however as a feature-fallout of the implementation, it is capable of extending in an anti-pattern (extending things yet to be declared). If what you're writing is an anti-pattern, it will throw a warning.
+- **Order of Processing/Specificity** In normal cases, the document is processed top-to-bottom; however, as a feature-fallout of the implementation, it is capable of extending in an anti-pattern (extending things yet to be declared). If what you're writing is an anti-pattern, it will throw a warning.
 - **Media-cross-media Inheritance** Attempting to extend a rule inside a media block from within another media block [is directly disallowed in the code](https://github.com/travco/postcss-extend#quirks) and will throw a warning.
-- **Silent placeholders** Includes both the stricter `@define-placeholder` and it's aliases for compatibility with [simple-extend](https://github.com/davidtheclark/postcss-simple-extend), and the `%` placeholder [from the spec](https://tabatkins.github.io/specs/css-extend-rule/#placeholder). As this isn't the native parser, the placeholder will be wiped from the CSS if it goes unused (as well as throw a warning).
-- **Subclass inheritance** Currently doesn't log a warning for it's use, as it is not stated in the spec for or against its behavior (despite it logically following). All [sub classes of an extended 'base' class are extended](https://github.com/travco/postcss-extend#extending-sub-classes-and-sub-elements), creating subclasses for the extending class as a means of mimicking the inheritance of specific sub-class contingencies (like `:active`)
-- **'Whiff' extension** trying to extend something that doesn't exist will log an error, and like everything else, remove the `@extend` rule.
+- **Silent placeholders** Includes both the stricter `@define-placeholder` and its aliases for compatibility with [simple-extend](https://github.com/davidtheclark/postcss-simple-extend), and the `%` placeholder [from the spec](https://tabatkins.github.io/specs/css-extend-rule/#placeholder). As this isn't the native parser, the placeholder will be wiped from the CSS if it goes unused (as well as throw a warning).
+- **Subclass inheritance** Currently doesn't log a warning for its use, as it is not stated in the spec for or against its behavior (despite it logically following). All [sub classes of an extended "base" class are extended](https://github.com/travco/postcss-extend#extending-sub-classes-and-sub-elements), creating subclasses for the extending class as a means of mimicking the inheritance of specific sub-class contingencies (like `:active`)
+- **"Whiff" extension** trying to extend something that doesn't exist will log an error, and like everything else, remove the `@extend` rule.
 
 
 ##### Originally a fork of davidtheclark's [postcss-simple-extend](https://github.com/davidtheclark/postcss-simple-extend) (extended) by way of the included [MIT License](https://github.com/travco/postcss-extend/blob/master/LICENSE)

New alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Fixed alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

43123

increased by2.2%

Lines of code

408

increased by2%

No dependency changes