watch doesn't trigger a new build on template changes

[waynehoover]

Not sure if this is an issue with spike-core or spike-records.

My records config looks something like this:

const records = new Records({
  addDataTo: locals,
  posts: {
    url: 'https://url-to-some.com/post.json',
    template: {
      transform: (data) => { return data.items },
      path: 'views/post.sgr',
      output: (post) => { return `/post/${post.fields.slug}.html` }
    }
  }
})

But every time I edit views/post.sgr I have to restart the server with spike watch which is actually for me an npm script npm start. But it happens if I run it as an npm script or globally.

[jescalan]

Hey Wayne!

So this is an outstanding issue, and it happens because templates generate multiple outputs on the fly from a single file, which is not something webpack is super amenable to (their cacheing mechanism makes it impossible), so the templates are processed separately and are not part of webpack's watcher.

This is annoying for sure and I have sunk a number of hours into it earlier, and plan on putting a bit more time into it this week or early next week, I have some more ideas on how to potentially fix.

In the meantime, it is much easier to just change any other file instead of restarting the watcher, and this will refresh the page. What I do when dealing with this is keep the css affecting the page open in a tab next to it, make a batch of changes, then flip over and hit command-S on the css, which will trigger a reload with the updated template.

I'll let you know if/when I have released a better fix for this issue!

[onionhammer]

@jescalan in addition, it also doesn't update for changes to a file, like new Records({ temp: { file: 'someFile.json' })

if I change someFile.json it will not trigger a hot reload. I feel like spike should have a better, more reliable mechanism and some samples for how to do this.

[jescalan]

I don't disagree. But it would be just wonderful if anyone was willing to contribute towards what they want! This is an open source project 😁

[onionhammer]

Hah, fair enough; but right now I'm trying to write a static website, not a static website library ;)

[jescalan]

So am I my friend, I wrote the library to help me make sites, not for the pure joy of library authoring. This is not an issue that is causing me problems, personally, and I am not being paid to resolve it, while I am being paid to do other things that are not resolving this, so it's unlikely I'll get to it soon, until the need arises.

If you'd like a speedy resolution you will have to pitch in. In general, this is the case with open source, unless you happen to find a maintainer who has the same problem that they want to fix for themselves, or is willing to work for you for free.

[onionhammer]

Sorry if it came across that I was saying you are personally obligated to do anything; I was not suggesting that. We all need to work on open source projects that we're interested in, and our bandwidth is always limited, but the attitude of "You want it? You implement it" in open source is prevalent, just add a "help wanted" tag and move on if you dont want to implement it, maybe the proposer will implement it or maybe someone else will.

[jescalan]

So I would say that "help wanted" is the default for all issues - you should not see an issue without the "help wanted" tag on it and assume that the maintainer(s) or someone else is going to take care of it for you.

If you are filing a ticket on an open source project, you should be willing to help. The person already put in the hours to write the code and make it available for you to use for free - expecting them also to troubleshoot for you for free unless they have gone through all their projects and added a "help wanted" tag to every issue doesn't strike me as a super reasonable expectation.

I did a writeup on this that might clarify my views. I hope that you agree and take steps toward contributing back to projects that you use, and that help you 😁