@declare: importing a less file without outputing

[ChrisCinelli]

Use case:

• You have an app that has 100 pages
• You have some LESS that is common to all pages (ex: mixins, colors variable, Twitter bootstrap etc).
• Each page has its own specific LESS styles.

How do you make sure that everything works as expected?

I have 4 choices:

1. Each page has a pageSpecific.less that has a @import 'global.less'. The cons are:
   • Each page will have to load a different .css file and and each of these .css files will have big chuck of CSS rules that are in common with each others. Result: the first time the user access a page they have to wait until a relative big .CSS is loaded where the most part of this files has been already shipped in previous pages. So we waste bandwidth and time to load what we have already shipped.
2. Each page has only global.less file that has include to page1.less, page2.less, ... , page100.less.
   • In this case the file is HUGE. It need to be loaded the first time slowing down a lot the page load.
   • It has a lot of rules that are not relevant to the specific page, each page content needs to be scoped to the page and if somebody forgets to do it, they can alter other pages styles.
   • When somebody changes just one CSS rule in one file, the whole file need to be shipped again so if you release often there is no advantage in using static assets caching and having a even bigger waste of bandwidth and time.
3. You give up reusing the mixins, the variables, etc in global.less and you have two LESS files for each page: global.less and pageSpecific.less. This does not work for me.
4. This does not exist yet and it is what I am suggesting to implement. If we could have a @declare directive, we could have two files in the page: global.less and pageSpecific.less. pageSpecific.less will have @declare 'global.less'.The result will be that pageSpecific.less will be able to use the mixins and the variables in global.less but the output of the compilation of pageSpecific.less will not include the CSS rules already compiled in global.less. In this way we will have the optimal use of bandwidth and quick transfers.

[matthew-dean]

First, I would suggest if you have page1.less, page2.less, ..., page100.less then that sounds a bit like a CSS organization problem which LESS can't fully solve. More class abstraction might lessen the load per page.

That aside, you can soon do this:

@import (reference) global.less

That will allow you to use any variables / mixins in global.less, but will not output any CSS classes within global.less. This feature is enabled in (I should know this, but don't off the top of my head) 1.4.0 or 1.4.1.

[ChrisCinelli]

Thanks, @import (reference) sounds awesome!

Two questions:

1. "you can soon do this" how soon? When is it going to be the next "official" 1.4.x release?
2. "More class abstraction might lessen the load per page". What do you mean by "more class abstraction" ? 100 pages was an exaggeration but we probably have 20-30 different views that have their own unique CSS that depend on the structure of those views (between 10 to 600 lines depending on the view). IMHO, the best way for developers and probably from the point of view of performances is that each view has is own CSS and the shared CSS is in the global.less file. Sure you can combine some of those CSS/LESS files but with what significant advantage?

[Soviut]

Are there no elements within those 20-30 views that could be abstracted into a higher order library? If so, then how many unique characteristics per view are there? If each view only has a few differences, why not simply have a single less file that is responsible for handling those differences. (The following assumes you have some sort of unique ID set in the body):

// USERS
#users {
  .call-to-action {
    font-size: 5em;
  }
}

// THANK YOU
#thankyou {
  .back {
    font-weight: normal;
  }
}

[ChrisCinelli]

That would be choice #2.
Our product has very pixel perfect custom views that requires a few extra rules.
Personally I think that #4 is the best choice.

When is v 1.4.x going to be releases on npm?

[lukeapage]

"you can soon do this" how soon? When is it going to be the next "official" 1.4.x release?

Its in 1.4.1 - on the 1.4.1 wip branch.

I really want to get some stuff released but I don't have time. I want to release 1.4.0 and then put 1.4.1 onto npm as an alpha.

you can download the repository from the 1.4.1 branch and just use it for now, if you want.

[ChrisCinelli]

From a deployment prospective npm -g install less is very convenient.
When you have a few machines and developers a one line installer saves a lot of time and you make sure that it gets done right.

Releasing should be one command line command using the Makefile.
See http://andreypopp.com/posts/2013-05-16-makefile-recipes-for-node-js.html

I understand that releasing implies also release note and updating of documentation.
Maybe you can delegate this part to someone else. It looks like there are some very active people here.

[jonschlinkert]

Yeah maybe one of us could put 1.4.1-wip on npm as well, but I want @lukeapage's thoughts on doing so first. I'm reading Luke's response to mean that he would like to wait, and I'm supportive of that if that's the case. Primarily because although it might be more convenient for folks to pull it down with npm, it's also more likely to result in new Issues on the Less.js repo before we've even officially launched 1.4.0. Anyway, this is a judgement call for Luke to make.

[ChrisCinelli]

IMHO there is something off here about how revision number are used:

• Once you have code in beta, it should be almost feature freeze and stay in beta for a specified period (1 month?) to give a chance to people to find bugs and point out problems. The next step may be a release candidate. Once there is confidence that it is not breaking older code (beside those documented and previously deprecated) and the new bugs are solved. it is usually ready to go out. So here you have a a 1.4.0b4 out and b1 went out in March. Do you have any regression bugs unaddressed? If not, it should probably be released.
• The new version with new features should have at least a minor release number (1.5.0 in this case). Revision numbers (1.4.x) should be reserved for bug fixes of 1.4.0.

Wikipedia explains it better than me : http://en.wikipedia.org/wiki/Software_versioning

I would also make sure that you test releases against popular projects using less.js (ex: Twitter bootstrap)
I also would be careful with breaking changes and making sure that things are deprecated before being removed. jquery has been pretty good with this and it also has the migrate plugin that make easy to find deprecated methods.

[jonschlinkert]

This original issue posted here wasn't about versioning philosophies. Please search the issues so we don't have to keep rehashing the same conversation.

[ChrisCinelli]

I searched for "revision" and "version". I scanned through the results and I found a few discussions about when to publish on npm and what to keep or not in the repo. I am glad you are having this kind of conversations. However I haven't find anything that make explicit less' versioning policy or why the new version with new features is 1.4.1 instead of 1.5.
I wonder how you will address a urgent bug that need to be fixed on 1.4.0 if you are actively developing new features on 1.4.1.
Version numbers are free ;-)

[matthew-dean]

@ChrisCinelli In general, what you're saying is not off-base. Versioning is typically done in the way you describe.

So, I agree. 1.4.1 should be 1.5.0 minimally; however, 1.4.0 should have been 2.0.0. As a team, we are in agreement about that now and are adjusting course moving forward. But, for the time being, we've left version numbers as they are and will make that course correction starting with 2.0. There's might be an opportunity to rename 1.4.1 as 1.5.0; we could look into that.

[jonschlinkert]

Version numbers are free ;-)

Agreed, I was just saying I think we've had the discussion several times on here. But... to your point those conversations probably aren't tagged as such, so my comment was probably unfair. apologies.

[lukeapage]

I'm happy to rename 1.4.1 to 1.5.0.. I'll do that.. would rather stick to a normal convention for version numbers from now on.

I haven't put 1.4.1 (read 1.5.0) on npm because it is not feature frozen.. though I may put the pulls in and then move everything with milestone 1.4.1 to 2.0

@ChrisCinelli with the alphas/betas we did for 1.4.0, alpha was "almost feature complete", beta was "feature complete, just accepting bug fixes" we do this in our spare time and I spend enough of my day job worrying about things like this, so when it comes to less I mainly do the bits I find fun (e.g. the coding/bugfixing). You are more than welcome to join us and help us keep to correct version numbers

[jonschlinkert]

I'm good with either. Let's just all get on the same page

[ChrisCinelli]

Regarding versioning, I am not too familiar with npm publish. I am not sure what is the best practice to publish future (not completely stable) releases. On my side there is the expectation that a vanilla npm -g install less will simply install the latest stable version. On the other hand, I am sure people would love being able to work with versions that have features that did not make it to the "stable" release yet. I wonder if the WIP branch can always be in "alpha" so a1, a2, etc can be released when some features are "done".

Glad to see things moving forward... two years ago when cloudhead was extremely unresponsive and nobody else was working on less, I thought the project was destined to a early dead.

I am happy to help out with the time I can spend on this. From the commit history it looks like you do not use a lot the fork workflow but you are mostly giving people the right to commit on the "official" cloudhead's repo. Am I wrong? If you give me commits right I will try to put some work into it.

[lukeapage]

you can tag a release and if you do that it won't be installed by npm install -g less.. to get a release tagged "beta" you can do npm install -g less@beta no reason we couldn't have a wip tag.

What is the fork workflow? I'm pretty much the only person committing to the repo at the moment. Its just I prefer rebasing peoples commits than merging them in. To give you commit rights we at the moment have to get @cloudhead to add you.. we do plan on eventually moving to a less organisation though, where we will have more control.

To save giving too many people commit rights I would probably suggest you do something via a fork and then a pull request.. if you pick up an issue with some disagreement on it, please shout about it first, otherwise you risk implementing a feature we don't want. Assuming you do a good pull request and still want it, we will then give you higher priviliges.. does that sound fair? I don't want to put you off, but I also don't want us handing out commit rights like candy..

[ChrisCinelli]

I tried @import (reference) on Less 1.4.2 and does not work. was it moved into the 1.5.0 WIP?

[ChrisCinelli]

I answer my own question after digging in the code. Yes, it is in the 1.5.0 branch. I hope it will be released sooner than later. Thank you for the hard work!

[lukeapage]

I hope to release a beta in the next week or so. You can install from npm
by specifying the github branch if you would like to help by trying it out,
reprting issues etc.