Incompatibility with less.js plugins (and potentially internal upgrade of less.js itself)

[Justineo]

Hi,

I'm a developer of a less.js plugin.

I noticed accord will override the version of the loaded engine object here:

engine.version = require(engine.__accord_path + '/package.json').version

But less.js has already exported its version data as less.version as something like [2, 6, 1]. And internally some of its plugins use this to check plugin compatibility. These plugins may not work after overriding the version with 2.6.1.

Because gulp-less is using accord so I was asked about “how to work with gulp”, which leads me here.

[jescalan]

Woah, super weird, I would never have expected that. It's ridiculous for a plugin to check it's peer dependency's version at runtime, rather than just using peerDependencies. It's also ridiculous for less to export it as an array instead of a semver string that can be checked and validated using the semver package. All parts of this pattern are really bad.

That being said, I'm not here to fix other packages' strange conventions, so it seems like the right approach for us in this case is to change it to __version to prevent any overrides. However, this would be potentially breaking for accord users with any and all other languages, which puts us in a bind.

In this case I think the right move is to make a special exception for less. I'll try to figure out a way to do this today. But I would also encourage less plugin authors not to use this, since generally it's a much worse programming practice than using peerDependencies.

[seven-phases-max]

Not to reopen the thread but just for the reference: Less compiler and its plugins may not be a node.js packages at all (hence can't rely on npm versioning and have to provide their own version of version number checking. For the same reason an author of the 20 lines of code plugin can't afford packing a semver faciity into a (for example) browser-side script version of his plugin).