1

I am making a package that provides some additionnal ui components for bootstrap. I chose to depend on the (awesome) nemo64:bootstrap package for the LESS bootstrap library.

My package has to provide additional LESS files that would require some of the bootstrap LESS variables (say @brand-success). The end user could very well have customized those variables.

The nemo64:bootstrap package provide a file (custom.bootstrap.import.less) with bootstrap variables for the user to include it where needed. It is also the place where the user is expected to customize its bootstrap. So I'd like to include this in my package's less file, but I don't know, from my package, where the end user will put this file.

I could assume the default path that is given has an example on the nemo64:bootstrap package documentation (/client/lib/custom.bootstrap.import.less) but if another package writer make a different choice, the packages will be incompatible.

Is there a way not to enforce a specific file architecture to end-users ?

William Ledoux
  • 146
  • 1
  • 6

3 Answers3

1

One solution is to export the LESS file as an asset on the server and have a build plugin that will copy the file in the app so that the user can @import it wherever needed.

This is done the same way nemo64:bootstrap does it, which is a bit hacky and require to split the package in two different packages. I explained everything in this gist

William Ledoux
  • 146
  • 1
  • 6
0

As far as i understand packages such as nemo64::bootstrap to compiles Bootstrap's CSS make only sense be cause of the default Less compiler of metreor compiles each less file in to a single css file. Unless the name of your Less files starts with a underscore (_) it will be compiled.

When compiling Bootstrap you should only compile the bootstrap.less file, all other files are only partials. Partials should only be imported and not be compile in a CSS files. Bootstrap's partials file names do not start with a underscore, so packages such as nemo64::bootstrap are use to compile Bootstrap and enable you to update Bootstrap later on.

For your package you can include the Bootstrap Less code your self. You should also built-in the Less compiler and make sure it will compile only your main file. An example can be found at: https://atmospherejs.com/bassjobsen/less-pleeease

After the above steps your main less file can contain:

@import "bootstrap";
@import "overrides";

and so on

Bass Jobsen
  • 48,736
  • 16
  • 143
  • 224
  • I don't want to include the boostrap less code myself, because the end user may have customized its boostrap less. Or maybe I missed something from your answer. But thanks because your comment lead me to another solution (see my answer) – William Ledoux Mar 21 '15 at 00:12
  • If customizing means that the end user should be enabled to change Bootstrap's Less variables, you should notice that Less uses lazy loading and last declaration wins for variables. So you can override every variable by putting it definition afterwards. See also http://lesscss.org/features/#variables-feature-lazy-loading – Bass Jobsen Mar 22 '15 at 23:23
0

I am not completely sure how to procede. But you can start by registering a handle with the same extension as your variables file. This is what I mean:

var handler = function (compileStep, isLiterate) {
  // This will get the file path from the handler
  var variablesFilePath = compileStep._fullInputPath;
  console.log(variablesFilePath); // print the path to the server when starting
}
// handler may also be a callback
Plugin.registerSourceHandler('bootstrap.import.less', {archMatching: 'web'}, handler);

That will create a handler from where you might be able to use the plugins API. For more information you can refer to the Meteor API docs.

Let me know how this works.

Aldo Funes
  • 1
  • 1