preprocessor-template-literals

Converts ES6-like template literals from a text blob (e.g. *.scss, *.styl, *.less) into preprocessor-friendly (unquoted/escaped) code.

Installation

npm i -D preprocessor-template-literals

Usage: CLI

ptl [options] input-file

-w, --watch          Watches the input file.
-p, --preprocessor   [sass, stylus, less]  Pick a preprocessor. Defaults to input's filetype.
-o, --output-file    The file to output the unquoted/escaped blob to. If this flag is omitted, will stdout.
-h, --help           Display this help text.

What?

This:

$fraction: `1/2`;
 
.foo {
  width: $fraction;
}
 
.bar {
  width: `calc(100% * ${$fraction})`;
}

...compiles to this:

.foo {
  width: 1/2; // pure SCSS would've converted this to 0.5 
}
 
.bar {
  width: calc(100% * 1/2); // pure SCSS, and other preprocessors, require weird/unwieldy syntax 
}

Why?

Magic sucks. $fraction: 1/2 becomes 0.5 when I really wanted 1/2, etc. But the main reason is because I want to use native preprocessors before PostCSS plugins.

The workflow looks like this: Native preprocessor -> CSS -> PostCSS -> CSS.

Works great with postcss-ant loops.

// SCSS 
$gutter: 45px;
$sizes: 1/2 30px auto;
$length: length($sizes);
 
div {
  @for $i in 1..$length {
    &:nth-child({$length}n + $i) {
      width: ant($sizes, $gutter)[$i];
    }
  }
}

Can't PreCSS fill this void?

Things like PreCSS don't have native preprocessor functionality. PreCSS is a collection of very modular PostCSS plugins that, when put together, attempt to piece together a preprocessor as feature-rich as Sass. 20 modular plugins do not make a native preprocessor. I found myself bumping into these limits.

I also ran into problems with PostStylus when introducing syntax Stylus craps its pants to.

I think trying to recreate preprocessors inside of PostCSS is silly. Why not just add an escaping mechanism and pass pure CSS to PostCSS as God intended?

Notes/Caveats

• I know ${$foo} looks redundant, but I want the syntax of this lib to match ES6 syntax as well as be the exact same for every preprocessor. For instance, $ variable prefixes -- although good practice -- aren't required in Stylus, and will throw an error in LESS. Just double check your variables if you're getting errors.
• This just does some unquote() (or ~ if you're using LESS) stuff so it's not bulletproof and it doesn't work with double quotes yet (if this takes off I'll tinker with it).
• unquote() and ~ add some spaces on each side. This sucks but for now I'm too lazy to convert this to a sprintf-like syntax. If it gets popular I'll implement it in a sprintf way to get rid of the spaces.
• As an added/unintended side-effect, you can do some very basic operations within the literals. For instance, background: \${url + position + repeat}`might compile tobackground: url(../img/bg.png) center no-repeat, and things like`${3 + 2}`become5. Unfortunately sinceunquote()adds a space to each side,`${3 + 2}px`would compile as5 px`. The space between the number and unit mean it can't be interpreted as a valid CSS length (minifiers won't get it either).

Todo

• Fix stdio and come up with good examples. This will save an entire tmp file from needing to be made. This needs to be done before this is useful.
  • node index test/stylus/in.styl | node_modules/.bin/stylus | node_modules/.bin/postcss -u postcss-calc > test/stylus/out.css works, but watch doesn't...
• Would really be nice to sprintf instead of unquote just to get rid of gross spaces.

Contribute

• npm i
• npm start
• Edit lib/index.js (ES6 with StandardJS code style. Babels down to ./index.js). Make sure you have an editorconfig plugin for your editor to avoid mixing tabs/spaces, etc.
• npm test