• this is a feature request, not a bug report, so I'm not really going to follow this issue template

The feature request

1. preact create typescript myproj
2. cd myproj
3. yarn serve

The yarn serve command fails, because there's no build/ folder. Here's a feature for convenience:

• if build/ doesn't exist when yarn serve is run, then run yarn build and then serve so no error occurs
• if I change some files and run yarn serve, I think (I haven't tested this) preact will serve the old files. preact should detect if the files have changed: if they have, build before serving

Regardless of whether the second part of this feature has already been implemented, the first part is still a minor feature that's worth having.

Implementation choices

I can't immediately recall libraries that do this, but I'm certain there are some major repositories that do this.

• there's a package on NPM that does this: https://www.npmjs.com/package/build-if-changed
• we could use git (I think), but I'm not a fan of this idea because if an ignored file changes, we should trigger a rebuild
• we could get hashes of every file and store a cache, and when build is triggered, recalculate hashes and see if they match: if they don't, rebuild, else, use the old build (this is a pretty much reimplementing the first option)

I think you're on the wrong repository, You meant to post this on preact-cli I'll transfer this issue for you.

If you want the serve command to always build the application, just change the command to run build first, like this:

"build": "preact build",
"serve": "yarn build && sirv build --port 8080 --cors --single",

That does work, but it'll cause unnecessary builds: if I make a change, build, and then 2 days later run yarn serve, I shouldn't have to wait for a rebuild if nothing changed.

If I make a change and don't build, then 2 days later the yarn serve command should trigger a build.

If my site happens to be large, waiting for builds can take a long time. This means I'll have to remember when I last built the site.

This is really just for user convenience, there's not a dire need for this feature request.

That's certainly true.

But with how fast builds are, even for large applications, I think this would just be an over complication. Besides, in the age of continuous deployment, the need to build for production locally is growing more rare anyhow.

This is a problem caching should be used to solve. Since there are over 1000 npm modules at play here, caching is sortof an upstream issue.

There's a lot of interest in providing a development server that bundles minimally and on-the-fly, addressing this issue in a less git-specific way.

Since there are over 1000 npm modules at play here, caching is sort of an upstream issue.

I'm not totally sure what you mean—if we track changes in the lock file (either yarn.lock or package-lock.json), then won't we know when the node_modules have changed? I do agree that this can be considered an upstream issue—we could leave this to sirv.

And I totally understand that this problem can quickly become non-trivial—I just think this is a useful feature to have in preact.

I do agree that this can be considered an upstream issue—we could leave this to sirv.

Sirv is just an application for serving static files, it has nothing to do with building the Preact application. That's all on the Preact CLI.

I do agree that this can be considered an upstream issue—we could leave this to sirv.

Sirv is just an application for serving static files, it has nothing to do with building the application.

Oh, you're right! Looking at my package.json, it looks like preact does the building. Maybe the best place to put this feature is in preact-cli. What do you guys think? Is this an issue worth keeping open (a.k.a. is this something that'll ever get implemented in preact-cli), or should I go ahead and close this?

We removed it because we didn't think there was much benefit of having it integrated

In dev, you generally want the full dev server and in prod you don't want to build (if you even use our serve command and not netlify / nginx)

FWIW Webpack 5 actually includes disk-backed caching, which is basically what the original proposal hints at. We could try it here to see if it's an improvement for build times.