Next.js: Why it doesn't exist an asset pipeline?

[StarpTech]

Question about Next.js

Hi, why it doesn't exist an assets pipeline in next.js by default? For example, as a developer I have to care about the following downsides:

• None of the files in the static folder will be post-processed or minified.
  Missing files will not be called at compilation time, and will cause 404 errors for your users.

• Result filenames won’t include content hashes, so you’ll need to add query arguments or rename them every time they change.

Copied from https://www.gatsbyjs.org/docs/static-folder/#downsides

What's the next.js way to archive that? I saw examples like with-hashed-statics it is a solution but not an established solution in the community. Therefore how can I combine it with a CDN?

[Timer]

This is a feature we're interested in exploring and probably will have an RFC soonish!

[timneutkens]

Can be achieved with #9524

[Janpot]

@timneutkens If I understand correctly, this issue is about importing static files in javascript/typescript. For instance like next-optimized-images or next-images or with-hashed-statics. I'm not sure how https://github.com/zeit/next.js/issues/9524 solves that.

[timneutkens]

@Janpot you'll be able to preprocess images, even images from external data sources, as you can use any server-side dependency in getStaticProps / getServerProps.

[Janpot]

@timneutkens I'm sorry, I'm still not following. Would you mind writing an example of a getServerProps function that does what you mean? Just some pseudocode is fine.

[timneutkens]

getServerProps() {
  // stuff you want to do to images
  // write them to .next/static
  // return paths to the images
}

[StarpTech]

I also can't follow how #9524 will solve it. We are talking about a strategy to deal with assets in a broader sense.

• https://www.gatsbyjs.org/docs/importing-media-content/
• https://www.gatsbyjs.org/docs/static-folder/

In Next.js we can only refer to the static aka public folder. Everything else is custom.

e.g

• result filenames also don't include content hashes so we need to worry about browsers caching their old versions
• no prefix support for assets. We have to construct the correct URLs of all assets.

[Janpot]

getServerProps() {
  // stuff you want to do to images
  // write them to .next/static
  // return paths to the images
}

Oh ok, then I understood correctly.
Wouldn't that impact page load time a lot? So I can't do expensive operations like optimization, hashing... even when caching the paths, wouldn't this result in unnecessary long cold starts? What if there's a relatively large amount of images? What if an error happens during this processing? What if I want to upload them to my CDN?

[timneutkens]

There’ll be ways to do getStaticProps on api routes soon.

[StarpTech]

Please reopen. An issue is not solved only because it could perhaps work in the future.

[Janpot]

There’ll be ways to do getStaticProps on api routes soon.

I think that could be made to work. Pity we'll have to rebuild already existing webpack tooling though.

[StarpTech]

Pity we'll have to rebuild already existing webpack tooling though.

That's the whole point of this issue.

[Janpot]

also, on second thought, I still don't see how you'd do content hashing of assets with statically generated api routes.

edit:

:thinking: maybe instead of hashing the content, one could add the build id in the api path or as query parameter. but that would result in unnecessary browser cache invalidations of course.