Make the ignoring of 'index' files an option

[jsahlen]

Not sure if this is useful to anyone else, but… I made the ignoring of 'index' files (as described in #20) an option, ignoreIndexFiles. If it is set to false, the defined structure will be used to construct the permalink, even for files with a basename of index.

[jonschlinkert]

Can you describe the use case(s) for this? What are some scenarios where you would want file paths for index files to be re-written?

I don't remember and haven't had a chance to look, but will this effect calculation of file paths, such as assets? (e.g. https://github.com/assemble/assemble-middleware-permalinks/pull/25/files)

related:

• Subfolder indexes omit permalinks structure #46
• Remove check against index basename #47
• https://github.com/assemble/assemble-middleware-permalinks/issues/
• adds logic to ignore permalink structures for files named "index". Also ... #23

Also, before we consider merging this we'll need to have tests (just additional targets in the Gruntfile) to show that it doesn't break anything else. I'm not too keen on the semantics either, but it's probably better than ignoreIndices. thanks for the pr!

[jsahlen]

My use case is that, I have a separate build task for blog posts (mostly because I use a different layout file for them). My structure is :basename/index.html, and my posts directory looks like this:

posts
├── post-number-one.md
├── post-number-two.md
└── post-number-three/
    ├── image-for-3.jpg
    └── index.md

Like I said, this may not be useful for anyone but me, and there might be better ways to handle this. When I was playing around with older versions of Assemble, I used the preprocess option of the pageCollection plugin to filter these things, but that seems to have gone away in 0.5.0. I'm well aware everything is still under heavy development though, so I would be more than fine with having this pr closed and waiting for a more proper way of doing things.

[jonschlinkert]

thanks for the detail! and no problem, I'm open to whatever makes sense, I just want to understand the use case a little better first.

Interesting, so post-number-three, is that a directory b/c of how the image or other similar assets are being handled? (I know that's just an example)

I have a separate build task

to clarify, do you mean a separate "target"? something like:

assemble: {
  options: {},
  site: {
    files: {
      'dest/': 'templates/*.hbs'
    }
  },
  // something like this?
  blog: {
    files: {
      'dest/blog/': 'posts/*.md'
    }
  }
}

I use a different layout file for them

How are you defining layouts? And how are you actually defining the src-dest stuff in the task? Maybe we should start with these things and go from there.

[jonschlinkert]

it would be great if you could post an example of your assemble task config from the gruntfile. even better if it's open source and you can share a link to the project...

[jsahlen]

Yes, that how i use the post-number-three directory – I think it's a nice way to bundle resources with the specific post they go with.

I use Gulp, hence the "task" terminology, but yes, same thing as using multiple targets in Grunt. Here's a simplified version of my gulpfile.js:

var path = require('path');
var gulp = require('gulp');
var assemble = require('gulp-assemble');

var assembleOptions = {
  assets: 'public/assets',
  layoutdir: 'src/templates/layouts',
  partials: 'src/templates/partials/*.hbs',
  layout: 'default.hbs',
  helpers: ['src/helpers/*.js'],
  middleware: ['assemble-middleware-permalinks'],
  permalinks: {
    structure: ':mybasename/index.html',
    replacements: [
      {
        // Custom replacements to work around the final filename being set as 'index/index.html'
        pattern: ':mybasename',
        replacement: function() {
          var basename = this.basename;

          if (basename === 'index') {
            basename = path.basename(path.dirname(this.src));
          }

          return basename;
        }
      }
    ]
  }
};

gulp.task('assemble-pages', function() {
  return gulp.src('src/pages/**/*.{hbs,md}')
    .pipe(assemble(assembleOptions))
    .pipe(gulp.dest('public'));
});

gulp.task('assemble-posts', function() {
  var options = _.extend({}, assembleOptions, {
    layout: 'post.hbs',
    permalinks: _.extend({}, assembleOptions.permalinks, {
      ignoreIndexFiles: false
    })
  });

  return gulp.src('src/posts/**/*.{hbs,md}')
    .pipe(assemble(options))
    .pipe(gulp.dest('public/posts'));
});

I'm feeling more and more like I'm going about things entirely the wrong way here. I don't want you to waste your time on this if I'm way off target :)

[jonschlinkert]

thanks again for the detail! you're not at all wasting anyone's time - it's great to have an opportunity to hear how assemble is being used. I wish I could get more users to share what they're doing!

Let me think about this, I'll try playing around with similar gulp configs locally.

In the meantime, have you tried defining layouts in the yaml front matter posts? this would eliminate the need for two different tasks. there are other things we can do if that's not ideal. also, fwiw in v0.5.0 you'll be able to define the actual destination for each file in the front matter as well :-) IMO that's pretty awesome, but I leverage the heck out of front matter - I know some folks have an aversion to it.

[jsahlen]

Great to hear that more things will be configurable in the front matter! I love front matter, but I really like my stuff as DRY as possible, so I'd rather not have to add a layout directive to every post. I might write a super small Assemble middleware though, doing something like ("if source file is in the posts folder and doesn't have a layout set in its front matter, set the layout to post.hbs") :)

[jonschlinkert]

that's a good idea. I don't mind writing it up if you want.

[jsahlen]

Nah, that's fine. I might look into it later if I feel I need it. Thanks though!