[WIP] Next.js Image Component

[timneutkens]

Keeping track of the feedback so far:

• Fix flashing of no-src image when using next/image #18195 Lazy loading flickers a <img> with empty or not found src icon
• Make lazy-loading the default for next/image #18123 Images that are rendered in a flexbox are not lazy loaded (@timneutkens)
• Make lazy-loading the default for next/image #18123 Lazy loading has to be the default (@timneutkens)
• Make lazy-loading the default for next/image #18123 Throw error when width and height are missing and unsized is not set (@styfle)
• Change Image component lazy=true to loading=lazy #18138 Rename lazy=true to loading=lazy to match web standard (@styfle)
• Update Image Optimization API to prevent upscaling image  #18147 Prevent upscaling images, API should never return an image width larger than the source image width (@styfle)
• Add docs for Image Optimization #18107 Add documentation for next/image and automatic image optimization (@styfle)
• Update redirect query encoding #18149 Correctly encode the url parameter (@ijjk)
• Add missing w param fallback #18151 Add missing w param for old browsers like IE that dont support srcset (@styfle)
• Add support for string width/height on Image component #18178 Add support for string width and height attributes (use parseInt and error) (@styfle)
• Add next/image default loader errors #18152 Errors from image optimization need to be surfaced, ie better message when absolute url is not in domains (@ijjk)
• Lazy loading can probably be converted to effect + state (@atcastle @devknoll)
• Add config limit checks for image optimizer #18217 Limit maximum number of images.domains and images.sizes to 50, maximum value of size to 10000
• Bypass image optimization for vector images #18179 Ignore svg for optimization (vector images can be considered already optimized) (@styfle)
• #5321 Only enable Vercel API in @vercel/next when loader=default (@styfle)
• Image Optimization API should 404 when loader is not default #18211 Only enable Next API when loader=default (@styfle)
• Fix Image srcset to ensure the component's width is the largest possible image #18236 Fix srcset to ensure the components width is the largest possible image (@styfle)
• Separate config into deviceSizes and iconSizes #18267 Separate deviceSizes and iconsSizes (@styfle)
• Add support number quality on Image Component #18224 The quality attribute should allow number or string like width (@ykzts)
• Fix trailing slash for default image loader #18298 Fix redirect in next dev for /_next/image/ to /_next/image (@styfle)
• E2E tests to compare next dev and Vercel deployments
• Add err.sh for image config errors #18424 Add err.sh for missing images domain #18325 Add err.sh links for all errors
• Deploy to nextjs.org (start with /next/conf) (@leerob)
• Deploy to vercel.com (start with @geist/image/new)

[todortotev]

I could lend a hand with these if needed.
Throw error when width and height are missing and unsized is not set
Add err.sh links for all errors

[kevva]

• Support AMP

[timneutkens]

• Support AMP

Given the current <img> usage requires replacement with amp-img it's not a goal of the RFC to support AMP initially. Should be relatively straight-forward to add support for it later though given we'll enforce width and height which AMP does as well.

[ItsWendell]

Great work on this, I've been following the RFC, canary developments and the above pull requests. In the RFC it was mentioned that there should be support for multiple CDNs at the same time.

We're modelling the way we save user-generated images now and notice that just saving the absolute url might not be enough, since then we can't make proper use of the next/image component. Now we're thinking of saving the root url, relative path, dimensions and source / provider (e.g. imgix / cloudinary).

According to the docs, loaders should be defined like this:

module.exports = {
  images: {
    loader: 'imgix',
    path: 'https://example.com/myaccount/',
  },
}

Now what if we are initially using cloudinary, later want to move to imgix or our own solution?

The RFC mentioned the following:

Support for files from multiple sources
It’s not uncommon for an application to feature images served from multiple image hosts. The Image component will support this through an optional host attribute that lets the user specify from one of multiple hosts declared in the next.config.js file. The component will use both the host substring and the loader registered to go along with that host in constructing the URL.

If no host attribute is supplied, the default host and loader will be used

I don't see any (work in process) PR's open for this functionality and it's not clear on how to implement this yet, is someone working on this and is this planned for the coming release?

[timneutkens]

I don't see any (work in process) PR's open for this functionality and it's not clear on how to implement this yet, is someone working on this and is this planned for the coming release?

Support for it was removed for the initial release given that it adds significant complexity in both implementation and configuration. It also caused more code than necessary to be shipped to the browser. We'll address it later if there's enough need for it. In general it's uncommon to be hosting on both imgix and cloudinary at the same time.