assemble / assemble-workshop

Recipes how to use assemble (v0.12.0+)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Issue in latest version of assemble

stefanwalther opened this issue · comments

Hi @jonschlinkert,

can you think of the reason why this is failing:

https://travis-ci.org/assemble/assemble-workshop/jobs/145969664

What did change in recent versions?
Does collection-basic not follow best practices?

Regards
Stefan

@stefanwalther looks like it's passing now. not sure why it was failing before

OK, I'll check and re-activate again, thx.

@jonschlinkert: No, actually still the same problem:
https://travis-ci.org/assemble/assemble-workshop/jobs/147597233

Note: running it locally also fully works, seems to be an issue with travis, same issue on appveyor: https://ci.appveyor.com/project/stefanwalther/assemble-workshop/build/1.0.13/job/ombo46ncv27phjqr

These 2 lines are probably causing a circular reference when the context is merged before doing the actual rendering.

So a deep-copy or clone would the probably do the trick, right?
I'll give it a try.

No, unfortunately that wasn't the case - I think:

Changed from:

view.data.articles = app.views.articles;
view.data.pages = app.views.pages;

to:

view.data.articles = _.clone( app.views.articles );
view.data.pages = _.clone( app.views.pages );

Results:

you can probably figure out the problem quickly by emitting listening for the errors. The error message, no writecb in Transform class, indicates that you probably don't have an error listener in the pipeline.

For debugging, try doing this:

app.src('foo').on('error', console.log)
  .pipe(bar()).on('error', console.log)

and add that .on('error', ...) listener to all of the things being piped

It looks like the goal is to expose those view collections on the context used in Handlebars when rendering. I think it's a better approach to just set them on app.cache.data by doing this inside the init task after the collections have been loaded:

app.data({
  articles: app.views.articles,
  pages: app.views.pages
});

Then remove the preRender middleware. Now the references to those collections will still be kept so changes made to the views and data on the views will still be updated (if needed).

Also, it's a good idea to listen for those errors to track down where the error is occurring. As Jon said, it should help track down the issue faster.

OK, thx again, will give it a new try ;-)

Hi @doowb,

also not works, by following your advice I get:
AssertionError: expected [RangeError: Maximum call stack size exceeded] to not exist

Again, the strange thing is that "my" approach still works on OSX, but not on travis (a pure Linux whatever distribution).

Still not idea how to make this test successful.

(And I actually use this approach in several of my solutions - so it is quite important for me ;-))

and add that .on('error', ...) listener to all of the things being piped