Rebuild components if a Base/* file is modified

[Macxim]

Right now, if I modify something in Base/base.less, the components are not built again, so changes aren't applied. The components have to be saved manually so that the change applies (or if I run npm run dsf again).

[lipsumar]

Base/Base.less (from the example project) is a dependency of all other components (because it is defined as "base CSS" in config.base.css).

Currently (0.2.0) DSF doesn't rebuild when dependencies change, which is clearly a priority.

[Macxim]

So, we want DSF to react to the following actions:

• Update dependencies (such as Base/Base.less (from the example project))
• Update component files (any modification (.hbs, .html, .less, .scss, .md, etc.) should rebuild it)
• Upon deletion of a file in public/_built/(not very likely to happen, though)

[lipsumar]

Should it watch public/ at all ? normally users are not supposed to touch it.

[Macxim]

Not really, I guess I was being lazy when testing.

[lipsumar]

hehe, but that's a good point. I totally see why you'd go and edit directly there. It's the danger of building: never touch the built files by hand.

I think DSF should either support it or be very clear about it. Supporting it would be very difficult, so I propose to warn the user if they do. It's their filesystem so it's impossible to prevent them from touching files. The best thing we can do is show them that it's not the way to go.

But maybe a decent auto-reload will be enough.

[lipsumar]

the more i think of it, pre-building is not a good idea. The main issue i have with my previous attempt is the build time. As soon as we reached about 50 components and 5 "themes" (basically very big components), the build time went way too high.

If the base css is modified and we rebuilt all components that depend on it (which is all of them), then we're in for a serious build time - or worse, freeze. I think it makes more sense to build on-demand. After all you can only work on one component at a time.

[Macxim]

That is a situation I didn't considered. On-demand build definitely sounds the right thing to do. :+1:

[lipsumar]

Here is how I see it: A component has a cache. It's purpose is to not read files from disk because it's slow. Each time a file changes, the component should update its cache. Not having to prebuild means it's much easier to handle dependencies (I think). As long as we keep caches up to date all generated code should also be fine.

After this re-caching occurs (which should include preprocessing but I'm not sure) we need to propagate an event so the UI can reload.

Btw, no prebuild means no public/_built at all :)

Emmanuel Sent from my mobile

Le 25 avr. 2016 à 08:16, Maxime Laforet notifications@github.com a écrit :

That is a situation I didn't considered. On-demand build definitely sounds the right thing to do.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

[Macxim]

But if there is a cache, there has to be a first build at some point. Am I right?

[lipsumar]

If we do on-demand builds, the first build (and all the others) will be done at the same time the browser requests HTML/CSS or JS. So no build until the user actually chooses to view a component through the UI.

[Macxim]

Understood.

[lipsumar]

We should probably start to distinguish 2 things:

1. dsf build
   Resolving dependencies and caching files in memory.
2. user build
   Any task defined in config.process. Not cached (although some caching might be added as an optimization later)

While the "user build" is executed on-demand, "dsf build" is done as soon as something changes and is cached. dsf build should be kept as small and fast as possible.