How to inject dynamic variables? Banner has had a breaking change.

[MarcDiethelm]

In 0.4.8 I used to be able to use (maybe abuse) the banner option to dynamically inject a variable for use with the Less parser like so:

banner: "@static-prefix: '<%=staticUriPrefixCss%>';"

After I upgraded to 0.5.2 today this is not possible anymore. The string is now simply prepended to the output, instead of being 'consumed' by Less.

Hmm. Is there a recommended way of injecting dynamic variables? Using banner for this did feel a bit hackish, admittedly. In an earlier commit I saw something about a variablesoption...

This feature is important to me. In the framework that I'm building this allows users to define an URI prefix to static assets once, yet have it reflected in the router and generated assets and so on. Perfect for possible later integration of a frontend in other, less flexible backends.

[jonschlinkert]

I think one of these should do what you need:

• https://github.com/assemble/assemble-less#process
• https://github.com/assemble/assemble-less#metadata
• https://github.com/assemble/assemble-less#pass-in-data-from-json-or-yaml

[MarcDiethelm]

Hmm, I'm afraid not. I was looking at all of these.

'Process' comes close, because it allows to use a variable that is defined in Gruntfile.js. However, I'd rather not process all the source files just to interpolate one instance of a Grunt template. Asset building is somewhat slow as it is already.

'Metadata' and 'pass in' depend on files in a specific format. This is pretty much incompatible with my setup, where the whole configuration of the framework is a product of deep merging JS(ON) from multiple files, most of which are edited by users. This config creation is done when starting the server/framework and each time a Grunt task is executed. The variable I need to inject into Less is defined during this process.

It would just be very handy to have a straightforward mechanism to inject some simple variables into the parser. The values of which are only known once Grunt is running its tasks.

[jonschlinkert]

I'm struggling to see exactly what you want to do, do you have a live example somewhere? it would help for me to see it live, and failing.

Also, if you care to share some of what you're working on, I might be able to help you improve even further. I'm working on other solutions that you might be able to leverage as well.

[jonschlinkert]

actually, let me look at 0.4.8 and see what I was doing differently too

[MarcDiethelm]

It's a bit difficult to describe what's going on in a GH issue. I hope this gives you enough pointers.

A live example... not currently. But it would not be very helpful to observe the framework only from the client perspective.

Of course you can look at the full source of the project, no problem. Feel free to clone and run the project from the develop branch. ;) The project is here: https://github.com/MarcDiethelm/xtc

npm start and npm test are set up.

For one there's the now failing test when using a banner to inject a variable: https://travis-ci.org/MarcDiethelm/xtc/jobs/11159778

This is the Grunt target 'less:external': https://github.com/MarcDiethelm/xtc/blob/develop/Gruntfile.js#L184 (At the top of this file you see an example of how the configuration is built. This mechanism is used in many tests and the app itself.)

Here's a the test fixture (.less) that uses the variable: https://github.com/MarcDiethelm/xtc/blob/develop/test/assets/fixtures/_base/css/elements/base1.less (Testing with this fixture fails earlier than the above test output indicates, because the variable is not defined. I added this part to the test after the initial failures. Nonetheless I need it to pass.)

If you have questions just ask. In the meantime thanks a ton for looking into this.

[MarcDiethelm]

I went ahead and made the changes to restore banner behavior. Includes tests.

Please ignore b8a39ed, it references a commit on a deleted branch, made before I added the tests. Github should not even show it.

[MarcDiethelm]

Can you publish the changes on npm? ...New installs of my framework will work again and Travis will report passing builds.

[jonschlinkert]

no prob, thanks for the reminder!

[jonschlinkert]

done. however the tests are failing. looks whitespace related

[jonschlinkert]

nvm, I fixed it