simonihmig / ember-responsive-image Goto Github PK

Automatically generate resized images at build-time, optimized for the responsive web, and using components to render them easily as <picture> elements.

License: MIT License

JavaScript 19.03% HTML 2.06% Handlebars 2.24% TypeScript 76.51% CSS 0.16%

ember-addon responsive ember responsive-images

ember-responsive-image's Issues

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

Lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Replace dependency eslint-plugin-node with eslint-plugin-n 14.0.0
Update dependency ember-template-lint to v6
Update dependency eslint to v9
Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

Update dependency glob to v10

Detected dependencies

github-actions

.github/workflows/ci.yml

actions/checkout v4

pnpm/action-setup v3

actions/setup-node v4

felixmosh/turborepo-gh-artifacts v3

actions/checkout v4

pnpm/action-setup v3

actions/setup-node v4

felixmosh/turborepo-gh-artifacts v3

actions/checkout v4

pnpm/action-setup v3

actions/setup-node v4

felixmosh/turborepo-gh-artifacts v3

actions/checkout v4

pnpm/action-setup v3

actions/setup-node v4

felixmosh/turborepo-gh-artifacts v3

.github/workflows/release.yml

actions/checkout v4

wyvox/action-setup-pnpm v3

changesets/action v1

npm

package.json

postinstall-postinstall ^2.1.0

@changesets/changelog-github 0.5.0

@changesets/cli 2.27.5

concurrently 8.2.2

prettier 3.3.0

turbo 1.13.3

node 20.14.0

pnpm 9.1.4

packages/cdn/package.json

@tsconfig/strictest 2.0.5

@typescript-eslint/eslint-plugin 7.11.0

@typescript-eslint/parser 7.11.0

concurrently 8.2.2

eslint 8.57.0

eslint-config-prettier 9.1.0

eslint-plugin-n 17.7.0

eslint-plugin-prettier 5.1.3

pkgroll 2.1.1

prettier 3.3.0

typescript 5.4.5

packages/core/package.json

@tsconfig/strictest 2.0.5

@typescript-eslint/eslint-plugin 7.11.0

@typescript-eslint/parser 7.11.0

concurrently 8.2.2

eslint 8.57.0

eslint-config-prettier 9.1.0

eslint-plugin-n 17.7.0

eslint-plugin-prettier 5.1.3

pkgroll 2.1.1

prettier 3.3.0

typescript 5.4.5

vitest 1.6.0

packages/ember/package.json

@ember/render-modifiers ^2.0.0

@embroider/addon-shim ^1.8.7

@embroider/macros ^1.0.0

blurhash ^2.0.0

decorator-transforms ^2.0.0

ember-addon-config ^0.1.1

ember-async-data ^1.0.3

ember-style-modifier ^4.0.0

@babel/core 7.24.6

@babel/plugin-transform-typescript 7.24.6

@babel/runtime 7.24.6

@embroider/addon-dev 4.3.1

@glimmer/component 1.1.2

@glimmer/tracking 1.1.2

@glint/core 1.4.0

@glint/environment-ember-loose 1.4.0

@glint/template 1.4.0

@rollup/plugin-babel 6.0.4

@rollup/plugin-node-resolve 15.2.3

@rollup/plugin-terser 0.4.4

@tsconfig/ember 3.0.8

@types/ember 4.0.11

@types/ember__application 4.0.11

@types/ember__array 4.0.10

@types/ember__component 4.0.22

@types/ember__controller 4.0.12

@types/ember__debug 4.0.8

@types/ember__destroyable 4.0.5

@types/ember__engine 4.0.11

@types/ember__error 4.0.6

@types/ember__helper 4.0.7

@types/ember__modifier 4.0.9

@types/ember__object 4.0.12

@types/ember__owner 4.0.9

@types/ember__polyfills 4.0.6

@types/ember__routing 4.0.22

@types/ember__runloop 4.0.10

@types/ember__service 4.0.9

@types/ember__string 3.16.3

@types/ember__template 4.0.7

@types/ember__test 4.0.6

@types/ember__utils 4.0.7

@typescript-eslint/eslint-plugin 7.11.0

@typescript-eslint/parser 7.11.0

babel-plugin-ember-template-compilation 2.2.5

concurrently 8.2.2

ember-cached-decorator-polyfill 1.0.2

ember-modifier 4.1.0

ember-template-lint 5.13.0

eslint 8.57.0

eslint-config-prettier 9.1.0

eslint-plugin-ember 12.1.1

eslint-plugin-n 17.7.0

eslint-plugin-prettier 5.1.3

prettier 3.3.0

rollup 4.18.0

rollup-plugin-copy 3.5.0

rollup-plugin-node-externals 7.1.2

typescript 5.4.5

@glimmer/component ^1.1.2

@glimmer/tracking ^1.1.2

packages/webpack/package.json

base-n ^3.0.0

blurhash ^2.0.4

loader-utils ^3.2.0

sharp ^0.33.0

@tsconfig/node20 20.1.4

@types/node 20.14.0

@typescript-eslint/eslint-plugin 7.11.0

@typescript-eslint/parser 7.11.0

concurrently 8.2.2

css-loader 7.1.2

eslint 8.57.0

eslint-config-prettier 9.1.0

eslint-plugin-node 11.1.0

eslint-plugin-prettier 5.1.3

glob 8.1.0

memfs 4.9.2

pkgroll 2.1.1

prettier 3.3.0

style-loader 4.0.0

typescript 5.4.5

vitest 1.6.0

webpack 5.91.0

webpack ^5.91.0

node 20.* || >= 22

test-app/package.json

@babel/core 7.24.6

@ember/optional-features 2.1.0

@ember/string 3.1.1

@ember/test-helpers 3.3.0

@embroider/macros 1.16.2

@embroider/test-setup 4.0.0

@glimmer/component 1.1.2

@glimmer/tracking 1.1.2

@glint/core 1.4.0

@glint/environment-ember-loose 1.4.0

@glint/environment-ember-template-imports 1.4.0

@glint/template 1.4.0

@tsconfig/ember 3.0.8

@types/ember 4.0.11

@types/ember__application 4.0.11

@types/ember__array 4.0.10

@types/ember__component 4.0.22

@types/ember__controller 4.0.12

@types/ember__debug 4.0.8

@types/ember__destroyable 4.0.5

@types/ember__engine 4.0.11

@types/ember__error 4.0.6

@types/ember__helper 4.0.7

@types/ember__modifier 4.0.9

@types/ember__object 4.0.12

@types/ember__owner 4.0.9

@types/ember__polyfills 4.0.6

@types/ember__routing 4.0.22

@types/ember__runloop 4.0.10

@types/ember__service 4.0.9

@types/ember__string 3.16.3

@types/ember__template 4.0.7

@types/ember__test 4.0.6

@types/ember__utils 4.0.7

@types/qunit 2.19.10

@typescript-eslint/eslint-plugin 7.11.0

@typescript-eslint/parser 7.11.0

broccoli-asset-rev 3.0.0

ember-auto-import 2.7.3

ember-cli 5.8.1

ember-cli-app-version 6.0.1

ember-cli-babel 8.2.0

ember-cli-dependency-checker 3.3.2

ember-cli-fastboot 4.1.5

ember-cli-fastboot-testing 0.6.1

ember-cli-htmlbars 6.3.0

ember-cli-inject-live-reload 2.1.0

ember-cli-sri 2.1.1

ember-cli-terser 4.0.2

ember-disable-prototype-extensions 1.1.3

ember-eslint-parser 0.4.3

ember-load-initializers 2.1.2

ember-page-title 8.2.3

ember-qunit 8.0.2

ember-resolver 11.0.1

ember-source 5.8.0

ember-source-channel-url 3.0.0

ember-template-imports 4.1.1

ember-template-lint 5.13.0

ember-try 3.0.0

eslint 8.57.0

eslint-config-prettier 9.1.0

eslint-plugin-ember 12.1.1

eslint-plugin-n 17.7.0

eslint-plugin-prettier 5.1.3

eslint-plugin-qunit 8.1.1

loader.js 4.7.0

npm-run-all2 6.2.0

prettier 3.3.0

prettier-plugin-ember-template-tag 2.0.2

qunit 2.21.0

qunit-dom 3.1.2

typescript 5.4.5

webpack 5.91.0

node 20.* || >= 22

Check this box to trigger a request for Renovate to run again on this repository

Still slow copy of images

From our TLW project:

[...]

165 images copied

[...]

4 images copied

Build successful (91877ms) – Serving on http://localhost:4200/

Slowest Nodes (totalTime => 5% )              | Total (avg)         
----------------------------------------------+---------------------
ImageResizer (2)                              | 29775ms (14887 ms)

I would guess this is caused by the call to extract the size meta data here.

At least the raw file copy time is neglectable (this is just one third of the number of files, but 3x more is still <0.2 seconds):

time cp -pr public/assets/img/responsive ./xxx

real	0m0.048s
user	0m0.002s
sys	0m0.032s

It seems the only thing used from the meta data call is the height, used to calculate the resized height here. But I am not sure we really need the height? For the srcset only the widths are relevant, and they are static (from the config), and don't depend on the image itself.

Set width/height attributes on <img>

See https://www.industrialempathy.com/posts/image-optimizations/#responsive-layout

Only as a default, user should be able to override.

Should we apply the auto-sizing CSS by default?

max-width: 100%;
height: auto;

Setup dependabot

Update htmlSafe import

https://github.com/kaliber5/ember-responsive-image/blob/v2.0.0-rc.1/addon/helpers/responsive-image-resolve.ts#L2
https://deprecations.emberjs.com/v3.x#toc_ember-string-htmlsafe-ishtmlsafe

Copying of images is pretty slow

160 images copied


Build successful - 97020ms.

Slowest Trees                                 | Total               
----------------------------------------------+---------------------
ImageResizer                                  | 93814ms

The copyImages method extracts the image meta data for each supported width, although that is always the same (for a given file). Probably moving this gm-stuff (https://github.com/kaliber5/ember-responsive-image/blob/master/broccoli-image-writer.js#L99-L105) out of the forEach loop can help to speed things up!

Support AVIF

Add fixed size support

Support fluid and fixed size images, similar to https://www.gatsbyjs.com/plugins/gatsby-image/#two-types-of-responsive-images.

Ideas:

switch to fixed mode by <ResponsiveImage @width={{500}} /> (sets width and height HTML attributes)
render the fallback src at this size (or best matching), and srcset for retina queries (1x, 1.5x, 2x)
add different config options for this use case, like

{
  // ...
  fixedSize: 800,
  pixelDensity: ['1x', '2x', '3x']
}

Support WebP

When starting to try to work on: ember-learn/ember-website#184

Wanted to try WebP for the image format for responsiveness, because by the team the above issue is resolved, WebP will probably be available in all browsers.

Remove `<ResponsiveBackground/>`

In an Octane world this can be better composed using the {{style}} modifier and our own helper.

Allow scoped file names

When multiple directories (say a and b) are set up in the addons config, having a file foo.jpg in both will not work, as the image is referred to only with its filename. I.e. <ResponsiveImage image="foo.jpg"/> is ambiguous. With many images in different configurations, it might be easily possible to get into name clashes.

We should support referencing files with a path, to add a scope to them.

What about something like this:

// config/environment.js

// ...
'responsive-image': {
  sourceDir: 'assets/images/responsive',
  destinationDir: 'assets/images/generated',
  // ... default image generation settings
  quality: 80,
  supportedWidths: [2048, 1536, 1242, 1080, 750, 640, 320, 150],
  
  overrides: [ // override settings for specific files, similar to eslintrc.js
      {
        dir: 'a',
        supportedWidths: [800, 400],
        // ...
      },
      {
        dir: 'b',
        supportedWidths: [160, 80],
        // ...
      }
  ]
}

This would lead to the following file handling:

assets/images/responsive/foo.jpg would be written to assets/images/generated/foo***.jpg and referenced as <ResponsiveImage image="foo.jpg"/>, using the default image settings
assets/images/responsive/a/foo.jpg would be written to assets/images/generated/a/foo***.jpg and referenced as <ResponsiveImage image="a/foo.jpg"/>, using the specific image settings
assets/images/responsive/b/foo.jpg would be written to assets/images/generated/b/foo***.jpg and referenced as <ResponsiveImage image="b/foo.jpg"/>, using the specific image settings

Instead of assigning configurations by folder, we could also do that by pattern matching. I.e. instead of dir: 'a' in config item, we could do pattern: 'a/*', or any other pattern to allow different settings within a single directory, e.g. pattern: '**/*-small.jpg'.

@andreasschacht thoughts?

Add Embroider support

Support rootUrl where baseUrl is missing

The baseUrl config option is deprecated, see http://emberjs.com/blog/2016/04/28/baseURL.html
When it is not available, it should use rootUrl here: https://github.com/kaliber5/ember-responsive-image/blob/master/addon/services/responsive-image.js#L124

consider making the computed properties `readOnly`

Just skimmed the add-on, and noticed many computed properties. Most (or all) don't make sense to be changed independent of the dependent keys they declare changing. (lets say via .set or some other accidental way).

It may be a matter of taste, but having debug many related heisenbugs I generally recommend computed properties to be marked as readOnly unless ofcourse they explicit support the set case (which in practice is rare).

The easiest way to do this, is as follows:

propertyName: computed('x','y', function() { /* ... code ... */ }).readOnly()

If you don't think this matters, feel free to disregard this issue. Anyways, cool add-on!

loading="lazy" by default?

https://www.industrialempathy.com/posts/image-optimizations/#lazy-loading

Add support for background images

We will need this for TLW sooner than later! :)

Could be a helper for simple elements and a mixin for components. Logic similar to that of the current implementation of the src attribute.

Probably makes sense to refactor things a bit, i.e. add a service that contains all the pieces (like the supportedWidths) that the component, helper and mixin can use.

Drop unsupported Ember versions

https://emberjs.com/releases/lts

Incompatible library version: libvips-cpp.dylib ...

Here is an exception I get when I run $ ember s:

Referenced from: ../node_modules/ember-responsive-image/node_modules/sharp/vendor/lib/libvips-cpp.42.dylib
Reason: Incompatible library version: libvips-cpp.dylib requires version 52.0.0 or later, but libvips.42.dylib provides version 51.0.0

OS: macOS 10.14.2
Node: 10.15.0
NPM: 6.4.1
Ember-cli: 3.7.1

There is an issue with removeSourceDir

So, if I put the content and run building process, for some reason it removes img folder from public/assets/ path, even though it logs only dist/assets/.

This is the config I've created:

var defaultConfig = {
  sourceDir: 'assets/img/',
  destinationDir: 'assets/generated',
  quality: 80,
  supportedWidths: [2048, 1536, 1080, 750, 640],
  removeSourceDir: true,
  justCopy: false
};

The problem could be associated with path I inserted into sourceDir, the last slash after img/ but not really sure to be honest.

Multi-Processing

We "parallelize" image processing here, but AFAICT this will still run in a single process as JS itself is single treaded. We could use https://github.com/josdejong/workerpool to increase performance (should be measured).

Support LQIP technique

Some background: https://jmperezperez.com/medium-image-progressive-loading-placeholder/

As we control the image generation at build time as well as the markup, we are in a good position to support something like this with zero effort for the user. Especially rendering the image with a really low-res image that is added inline with a Data URI should be a nice solution, as no additional request is needed.

This idea needs to be fleshed out a bit more though, like downsides of inlining (increases JS payload for every image) vs. additional request etc.

Reduce image meta size

Status quo

We write meta data as JSON into a <script> element of index.html. This is needed for the service/component to know which sizes (and now also image formats) of a given image are available, and what the URL for each size/format pair is.

Here is an example of a single image's meta data:

image meta

{
  "assets/images/projects/screenshots/ERGO/ergo_screen_05.png":{
    "images": [
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05640w.webp",
        "type": "webp",
        "width": 640,
        "height": 481
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05640w.avif",
        "type": "avif",
        "width": 640,
        "height": 481
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05640w.png",
        "type": "png",
        "width": 640,
        "height": 481
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05320w.webp",
        "type": "webp",
        "width": 320,
        "height": 241
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05320w.avif",
        "type": "avif",
        "width": 320,
        "height": 241
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05320w.png",
        "type": "png",
        "width": 320,
        "height": 241
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05750w.webp",
        "type": "webp",
        "width": 750,
        "height": 564
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05750w.avif",
        "type": "avif",
        "width": 750,
        "height": 564
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05750w.png",
        "type": "png",
        "width": 750,
        "height": 564
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05280w.webp",
        "type": "webp",
        "width": 280,
        "height": 211
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05280w.avif",
        "type": "avif",
        "width": 280,
        "height": 211
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05280w.png",
        "type": "png",
        "width": 280,
        "height": 211
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05590w.webp",
        "type": "webp",
        "width": 590,
        "height": 444
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05590w.avif",
        "type": "avif",
        "width": 590,
        "height": 444
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_05590w.png",
        "type": "png",
        "width": 590,
        "height": 444
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_051180w.webp",
        "type": "webp",
        "width": 1180,
        "height": 887
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_051180w.avif",
        "type": "avif",
        "width": 1180,
        "height": 887
      },
      {
        "image": "/assets/images/projects/screenshots/ERGO/ergo_screen_051180w.png",
        "type": "png",
        "width": 1180,
        "height": 887
      }
    ],
    "lqip": {
      "type": "blurhash",
      "hash": "g9T9Is?bof%MRj?bRj~qofWBofofofj[t7RjWUt7WBWVj]_3ozofj[ozofj[M{ayj[RjWBayWB",
      "width": 7,
      "height": 5
    }
  }
}

Problem

The meta data size can grow considerably. Especially now with 3 image formats generated by default (jpeg/png, webp, avif). While looking closer at the performance impact the introduction of responsive images to the kaliber5 website (see https://github.com/kaliber5/kaliber5-website/pull/218) had, using our Lighthouse-CI server, it became apparent that for pages with no/few images (no potential for improvement) the change actually yielded a perf regression. Specifically longer times for e.g. TTI and blocking time. See https://lhci.kaliber5.de/app/projects/kaliber5-website/compare/39b4ad0b1ac9

After spending quite a bit of time looking into it, and also introducing some improvements here (#177, #178), I am coming to the conclusion that the meta data is mostly the remaining problem responsible for this, occupying bandwidth that delays the loading of the JS assets.

If you look at https://staging.kaliber5.de/de, the meta data account for ~230KB (uncompressed) / 17KB (gzipped). You see that gzip is quite effective for that textual data, but still that 17KB is quite notable. And it doesn't get better with more sizes or images.

Possible solution

The meta data is highly redundant. Removing/shortening all the repetitive stuff (image paths, keys like width etc.) does not yield any significant improvements, as gzip does exactly that for us already. But we could try to be less explicit, as for example the generated file names are all deterministically created. So instead of the above image meta data, it could look like this:

image meta

{
  "assets/images/projects/screenshots/ERGO/ergo_screen_05.png":{
    "widths": [640, 320, 750, 280, 590, 1180],
    "formats": ["png", "webp", "avif"],
    "lqip": {
      "type": "blurhash",
      "hash": "g9T9Is?bof%MRj?bRj~qofWBofofofj[t7RjWUt7WBWVj]_3ozofj[ozofj[M{ayj[RjWBayWB",
      "width": 7,
      "height": 5
    }
  }
}

This would be enough to deduce all the previous information.

There is a caveat though: this would not work with fingerprinting. Images should be fingerprinted in production, and broccoli-asset-rev will do that, but to let the image meta data point to the final images including their fingerprinting hash, the un-fingerprinted full file path must exist there, so it can rewrite it.

The only solution that comes to my mind is to do our own fingerprinting. The generated images only depend on the original one, and their image processing configuration (e.g. quality setting). Creating a hash for esch generated image is actually not necessary. So we could create a hash based on the original image and its configuration and put it into the above meta data. On the build-time side, the image processor would create the generated images including this hash in their file name. On the run-time side, the service/component would know the hash (given in the meta data) and could deduce all required filenames based on the hash, the available sizes and formats.

We must then make sure that broccoli-asset-rev does not operate on our already fingerprinted files. Hopefully this should be possible, by letting our addon modify the app's config of broccoli-asset-rev, and filling/extending the exclude array with globs generated by the list of images we processed.

LQIP not rendered in FastBoot

Applied through the style modifier which does not run in FastBoot. Needs fix + tests.

Addon doesn't work as a nested dependency

Hey folks 👋 First of all I want to say thanks for a great addon! It's super useful and I'm trying to make it a key addon in a lot of the empress projects 🎉

I'm having a few issues right now where I want to make this addon work as a dependency of a dependency. There are a few issues that stem from the fact that certain hooks are not called in a nested fashion (like contentFor() ember-cli/ember-cli#8077) but there are other issues that seem to stem from the fact that we seem to have quite a few local variables in the addon that are not part of the general addon spec 🤔

You can see my attempts to defer some of the implementation of contentFor() and postProcessTree() to ember-responsive-image here empress/empress-blog-casper-template#37 but as you can see from the Netlify demo apps and build history, I'm not getting very far 🙈

If you have any advice on how to proceed that would be super useful 👍

Remove jQuery

Just used for a trivial thing here: https://github.com/kaliber5/ember-responsive-image/blob/be441d181df06cc528a56f8ced64bef60eceffee/addon/instance-initializers/responsive-meta.js#L6

Also add the no-jquery ESLint rule

multiple configurations

Add the possibility to define different configurations for different source directories

LQIP

https://www.industrialempathy.com/posts/image-optimizations/#blurry-placeholder

With native lazy loading (#89), do we still need the addon-addons (https://github.com/kaliber5/ember-lazy-responsive-image + https://github.com/kaliber5/ember-cli-lazysizes), or should we simply apply the blurry placeholder within this addon? (by default or opt-in)

https://github.com/google/eleventy-high-performance-blog/blob/main/_11ty/blurry-placeholder.js

Incremental rebuild not working

When I add a new image, this does not trigger resizing of the new image, and a new rebuild of the meta data. Instead this happens:

Ideally, it would not rescale all images, but only the changed ones. But even rescaling all images would be better than having to restart the ember server.

Add sprites support

May be related - #172, ember-learn/ember-website#769

Case:

Download list of small images

Current behavour:

Depends on network capacity and images count, images may blink and produce 10+ network requests to show some "near" UI elements.

Why sprites:

If we will be able to glue images of relatively same size into one sprite (adaptive one), I think we can unblock more network capacity and save more IO time.

In theory, sprite size should be samller than summ of all image sizes.

Sprites may be "chuncked" by dimentions, image "paths", image sizes, etc.

Refactor to (lightweight) Glimmer components

Also make sure that HTML attributes are properly passed (i.e. ...attributes)

Incorrect image paths on Windows

When I build on Windows, I get broken paths to the images, because the paths have backslashes (presumably because this is the Windows file separator) rather than the forward slashes that are required in URLs. I was able to fix this by replacing the backslashes with forward slashes using a regex like this:
let correctImagePath = originalImagePath.replace(/\\/g, '/');

I believe if this was done with image variable in the line linked below, it would fix the problem. There may also be a better solution using a path.posix method rather than path.join (because path.join uses the system separator rather than always using a forward slash).

https://github.com/kaliber5/ember-responsive-image/blob/7108fe95571296f35d7515a8577dacbd9f4debe3/broccoli-image-writer.js#L129

Support ...attributes

I was thinking about implementing: ember-learn/ember-website#184

but immediately ran in to an issue where not all attributes are forwarded to the rendered element. :-\

Add dominant color LQIP strategy

Allow fingerprinting of generated images

This addon allows resolving the fingerprinted asset path, even when generating the path dynamically: https://github.com/RuslanZavacky/ember-cli-ifa. This could solve the current problem having to turn off fingerprinting for our generated images.

We could either add ifa as a dependency to this addon so it is always available. Or dynamically detect its presence and add support for it when available.

Should we change/rename the component API?

Currently the basic invocation of the component looks like <ResponsiveImage @image="some/image.jpg"/>, and that does not change so far in the upcoming v2.

However as there are so many breaking changes (not really hard to fix, but just a bunch of them), we have the opportunity now to add more breaking changes, if we think they are justified.

My current thinking goes towards aligning the API more to match what a plain image tag would look like:

<Image @src="some/image.jpg"/>

vs.

<img src="some/image.jpg"/>

Maybe using Image as the component name could lead to conflicts with other components of user's apps though? Unless we get template imports, component names are still global and static, so that could be bad? (There is still an escape hatch by re-exporting the component in the app under a different name/module though!)

Maybe just rename @image to @src, therefore? I.e. <ResponsiveImage @src="some/image.jpg"/>

Or keep everything as it is now? 🤔

@andreasschacht @lolmaus thoughts?

Remove Mixins

blurhash support

ref: https://blurha.sh/
related ember addon https://github.com/lifeart/ember-blurhash

It will be great to have an option to generate blurhash hashes

Upgrade sharp

Using the old version of the sharp dependency breaks builds on Windows.

Migrate back to QUnit

Improve resize speed

https://github.com/lovell/sharp seems to be able to do the job much faster. And another pleasant side effect: it is free of any (non-npm) dependencies, so does not require the user to have imagemagick installed!

Performance comparison: http://sharp.dimens.io/en/stable/performance/#results

Optimize for FastBoot 1.0

@andreasschacht #18 is not optimal as we discussed it. A recent feature of ember-cli-fastboot (not yet released) allows us to easily inject stuff into the the FastBoot app's package.json, this is I think the missing piece we were looking for some time ago. See ember-fastboot/ember-cli-fastboot#374

Support FastBoot

At least at this point this is breaking FastBoot: https://github.com/kaliber5/ember-responsive-image/blob/master/addon/services/responsive-image.js#L168

[Feature request] Make it possible to export the image meta data as JSON files

I'm creating a portfolio website which has multiple pages with a lot of images each. It would be nice if I could configure this addon in some way that it outputs JSON files with the image meta data instead of embedding it all in the index.html.

That way I could manually fetch these files and add the data to the service on demand. Combined with FastBoot's Shoebox this would allow me to only include the minimum amount of meta data in the HTML body.

Do you think something like this would be a good addition or is it a niche use case?

Setup Github actions

Add lazy rendering

https://www.industrialempathy.com/posts/image-optimizations/#lazy-rendering

how do you install this since a dependency, sharp, has an install script, but I have ignore-scripts as a default for safety reasons

There must be a way to manually run sharp's install hook 🤔

Using the screen width rather than the viewport width results in too-large images

Hi, thanks for the addon, it's very useful :)

I might have missed there being some reason for this, but using the screen width as the base for picking the image size (in getDestinationWidthBySize()) seems incorrect. On desktop, the screen size isn't necessarily the same as the browser viewport size (since the browser can be resized), which means the helpers, components, etc. that get the "best fitting" image over-estimate the on-page size of the image if the browser isn't fullscreen.

I think it'd make more sense to use $(window).width() (or document.documentElement.clientWidth).

ImageMagick installation instructions

I installed ImageMagick 7 on Windows. I was getting an error when trying to build until I reinstalled and selected the option to "Install legacy utilities (e.g. convert)". The "Install ImageMagick" instructions should be updated to note that installing legacy utilities is required to make this work if you use the ImageMagick installer.

[Windows] imageName lookup fails due to filepath inconsistencies

On a windows machine, the metadata object of images uses backslashes and forward slashes inconsistently, since one path comes from the browser and the other comes from Windows itself. This causes the key lookup to fail here:

https://github.com/kaliber5/ember-responsive-image/blob/master/addon/services/responsive-image-local.ts#L52

The likely fix is to add a case to the normalizeImageName method here: https://github.com/kaliber5/ember-responsive-image/blob/f72157adabe0e055e750bd5167882c77bf78d707/addon/services/responsive-image-local.ts#L58

Allow file paths as sourceDir

It would be very useful to be able to assign a file path to the sourceDir configuration. With the current configuration, you are forced to organize your resources in a way that is amenable to defining the configurations per folder, which can make things a little messy.

For instance, on our homepage, we have a hero image that needs to be resized with a specific set of dimensions. There is also a background image on that page that needs a different set of dimensions. We wish to keep these two images in the same assets folder, but process them differently. In order to achieve this with the current ember-responsive-image we must place each image in a folder by itself so that we can define separate configurations.

This has a slight orthogonal relationship to #50