We can make this plugin more foolproof.
If I refer to same property, I need to get proper error.

.elem {
  color: @color;
}

Now I get meaningless Maximum call stack size exceeded.

Seeing this issue in codebases that were using the old version with no problem:

.Logo {
  text-align: center;
  display: block;
  color: inherit;
  font-family: "Yanone Kaffeesatz", "Helvetica Neue", Helvetica, Arial, sans-serif;

  @media (--md-viewport) {
    background-color: var(--color-gray-faint);
    border-right: 1px solid var(--color-gray-lighter);
    border-left: @border-right;
    padding: 5px;
  }
}

In the output CSS the @border-right value remains. I will add a test case for this tomorrow, this is just so I remember.

For those, like me, who are still "stuck" on the PostCSS 4.x path, because of certain plugins not yet supporting PostCSS 5.x, I could really use the 4.x version of this plugin (for now); however, there have been some fixes of recent that are not on the 4.x path.

Would you consider creating a postcss-4.0 branch, to which I can submit a PR that has all the new fixes?

Basically, I would just take the existing master branch, change the PostCSS dependency to 4.x and replace root.walkRules() with root.eachRule(). Perhaps it can be pushed as postcss-property-lookup version 0.4.0.

How does that sound?

/node_modules/postcss-property-lookup/build/index.js:38
    throw new Error('Invalid logLevel: ' + options.logLevel);
          ^
Error: Invalid logLevel: undefined
    at propertyLookup (/node_modules/postcss-property-lookup/build/index.js:38:11)
    at Object.creator [as plugin] (/node_modules/postcss/lib/postcss.js:60:39)
    at /index.js:97:27
    at Array.forEach (native)
    at /index.js:84:13
    at creator (/node_modules/postcss/lib/postcss.js:60:39)
    at Function.postcss.plugin (/node_modules/postcss/lib/postcss.js:66:23)
    at Object.<anonymous> (/index.js:78:26)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)

I believe the issue may be related to passing an empty object as options to the plugin.

I'm using the plugin with sass-loader and webpack. After watching for 30 minutes or more it results in a memory leak - the node server crashes. Also, the watch compile time becomes very slow (maybe 1.2 - 1.5 times slower).

I am getting this error on the new release:

/home/jiayu/iffedu/node_modules/precss/index.js:104
            instance.use(processor.plugin(processorOptions));
                                   ^

TypeError: processor.plugin is not a function
    at /home/jiayu/iffedu/node_modules/precss/index.js:104:27
    at Array.forEach (native)
    at /home/jiayu/iffedu/node_modules/precss/index.js:91:13
    at creator (/home/jiayu/iffedu/node_modules/postcss/lib/postcss.js:60:39)
    at Function.postcss.plugin (/home/jiayu/iffedu/node_modules/postcss/lib/postcss.js:66:23)
    at Object.<anonymous> (/home/jiayu/iffedu/node_modules/precss/index.js:85:26)
    at Module._compile (module.js:425:26)
    at Object.Module._extensions..js (module.js:432:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:313:12)

and everything works fine when i switch back to 1.1.3.

This requires a major version bump. See https://github.com/postcss/postcss/releases/tag/5.0.0

Some lookupped values may be unitless.
But others must use units:

/* input */

.body {
    line-height: 1.5;
    font-size: @line-height;
}

/* output */

.body {
    line-height: 1.5;
    font-size: 1.5;
}

I need to get:

/* output */

.body {
    line-height: 1.5;
    font-size: 1.5em;
}

For example, we can use this syntax font-size: @(line-height)em;

What do you think about supporting @parent like so?

.foo {
    color: red;
}

.bar {
    color: @parent.foo.color; /* yields red */
}

Theoretically, this would only go up one level with nesting:

.foo {
    color: white;
    &:hover {
        color: red;
    }
    .baz {
        color: @parent.color;       /* yields white */
        color: @parent:hover.color; /* yields red   */
    }
}

I suppose it would make sense to support @root as well:

.foo {
    color: white;
}

.bar {
    &:hover {
        color: @root.foo.color; /* yields white */
    }
}

It seems if you use this plugin in a .Parent selector then also use it in a nested .Child selector, the value in .Parent gets incorrectly taken from the equivalent in .Child.

In this case should use the padding-left value from .Parent not the one from .Child.

Instead this input:

.Parent {
  padding-left: 5px;
  padding-right: @padding-left;

  .Child {
    padding-left: 10px;
    padding-right: @padding-left;
  }
}

Produces this output:

.Parent {
  padding-left: 5px;
  padding-right: 10px;

  .Child {
    padding-left: 10px;
    padding-right: 10px;
  }
}

I've opened a PR (#2) which adds a test to reveal this issue.

In test/fixtures/out/default.css invalid property is going to output. Maybe better option is not include invalid property and show warning in terminal? Plugin for console warnings.

.Test2 {
  margin-left: 400px;
  margin-right: 400px;
}

https://github.com/jonathantneal/precss/wiki/Options

precss({"lookup": { disable: true }})

precss: base.css:26:1: Unable to find property @font-family in body
precss: base.css:26:1: Unable to find property @font-color in body
precss: base.css:92:1: Unable to find property @code-color in .loading__wrapper
precss: typography.css:18:1: Unable to find property @header-color in h2
precss: typography.css:18:1: Unable to find property @header-color in h2
precss: typography.css:18:1: Unable to find property @code-color in h2
precss: typography.css:30:1: Unable to find property @sheader-color in h3
precss: typography.css:37:1: Unable to find property @sheader-color in h4
precss: typography.css:44:1: Unable to find property @sheader-color in h5
precss: typography.css:51:1: Unable to find property @sheader-color in h6

How to disable this plugin?