Could you also allow localhost:${port} in DOMAIN_REGEX?

[shuuuuun]

Before you submit:

• [x] Please search through the existing issues to see if your feature has already been discussed.
• [x] Please take a moment to find out whether your idea fits with the scope and aims of this project.

Is your feature request related to a problem? Please describe.

When using ImgixClient._buildURL in the development environment, I am having trouble with an error if the url contains http://localhost:3000.

> ImgixClient._buildURL('http://localhost:3000/path/to/image.png', { w: 400, h: 300 })

Uncaught:
Error: Domain must be passed in as fully-qualified domain name and should not include a protocol or any path element, i.e. "example.imgix.net".
    at new ImgixClient (/frontend/node_modules/@imgix/js-core/dist/index.cjs.js:287:13)
    at Function._buildURL (/frontend/node_modules/@imgix/js-core/dist/index.cjs.js:497:20)

Describe the solution you'd like

I think adding a regular expression in DOMAIN_REGEX that allows localhost:${port} would solve the problem.

Describe alternatives you've considered

I am not aware of an alternative. If there is a way to work around this, I would appreciate it.

Additional context

• I am checking with v3.3.0, but the latest version v3.6.0 seems to be the same.

• Where the error occurs: https://github.com/imgix/js-core/blob/v3.3.0/src/index.js#L31-L36 https://github.com/imgix/js-core/blob/v3.6.0/src/index.js#L31-L36

• DOMAIN_REGEX definition: https://github.com/imgix/js-core/blob/v3.3.0/src/constants.js#L4 https://github.com/imgix/js-core/blob/v3.6.0/src/constants.js#L4

• My actual environment uses vue-imgix, which internally uses ImgixClient._buildURL. https://github.com/imgix/vue/blob/v2.9.0/src/plugins/vue-imgix/vue-imgix.ts#L47-L70 https://github.com/imgix/vue/blob/v2.9.0/src/plugins/vue-imgix/vue-imgix.ts#L76-L83

• In my use case:

  • I receive the URL to display the image via API and generate the img tag using the imgix sdk.
  • The API response already contains origin(protocol + host).
  • The imgix domain is used in the production environment and localhost in the local development environment.
  • In the local development environment, I would like to refer to the localhost image without using the imgix domain.

Thank you.

[sherwinski]

Hey @shuuuuun and thanks for opening this suggestion. We've received similar questions to this in the past but since imgix does not support locally-served images, a change like this would be considered out of scope for a library like this. I would be curious to hear more about your use case and how this feature helps to support it. Thanks!

[shuuuuun]

@sherwinski Thanks for your reply!

My use case is as follows.

• I am using the ix-img tag from vue-imgix. https://github.com/imgix/vue#basic-use-case https://github.com/imgix/vue/blob/v2.9.0/src/plugins/vue-imgix/ix-img.tsx
• In some places I am using buildUrlObject function manually to use srcset. https://github.com/imgix/vue#buildurlobject https://github.com/imgix/vue/blob/v2.9.0/src/plugins/vue-imgix/vue-imgix.ts#L47-L70
• They are internally using ImgixClient._buildURL. (when protocol is included) https://github.com/imgix/vue/blob/v2.9.0/src/plugins/vue-imgix/vue-imgix.ts#L76-L83
• The URLs specified for src or function are obtained from the server via API.
  • The API response already contains origin(protocol + host).
  • The imgix domain is used in the production environment, and localhost in the local development environment.
• While still using the ix-img tag, I want to be able to reference images on localhost in the local development environment.
  • It is complicated to use different img tag and ix-img tag depending on the environment or domain.

I am using vue-imgix in my case, but I think this issue is not limited to that. I think it always happens when you get an image URL including origin via API and specify it to src through this library.

If there is a way to work around this without changing the library, I would be interested to know.

Thank you.

[sherwinski]

Hey @shuuuuun, thank you for providing more details and apologies for the delayed follow-up here. To answer each of your questions:

1. There isn't an out-of-the-box solution to this issue offered in this library currently. Unfortunately, switching between img and ix-img seems to be the best work around at this point.
2. We have received similar requests in the past to what you are asking for here. From our standpoint, these libraries are primarily focused on serving imgix URLs/images; therefore supporting functionality aside from that feels out of scope from that focus.

Having said that, I will bring this issue up in our next team meeting and see what others think as well. I will update this thread once I have more information.

[sherwinski]

Hi @shuuuuun,

After discussing it further with the team, we've ultimately decided not to support this request. The reason being that this library is meant to facilitate the reliable construction of URLs tied to the imgix rendering service. By expanding the validation rules, we are losing the ability to guarantee that reliability. And while we generally try to leave wiggle room for developer convenience, doing so in this case to support images not served through imgix feels a bit too out of scope for this project. Apologies and hope you can understand our position.

With that said, I think there is another workaround that you could considering using in your case. Instead of using localhost in your dev environment, you can use dummy domain such as sherwinski.imgix.local:

import URLBuilder from '@imgix/js-core';

let ub = new URLBuilder({
  domain: process.env.NODE_ENV === 'production' ? 'sherwinski.imgix.net' : 'sherwinski.imgix.local',
});

Then edit your local hosts file so that sherwinski.imgix.local resolves to localhost:

# /etc/hosts
127.0.0.1 sherwinski.imgix.local

Hopefully this helps you. I am going to close this issue for now but please feel free to comment back if any other questions come up.

Edit: Assuming you want to specify the port, you will likely need to set up a reverse proxy as the hosts files only handles hostnames.

[shuuuuun]

Thank you for your consideration. I understand your decision.

In my case, the workaround of switching img and ix-img seems to be a good one. Editing the local hosts file would be a hassle to share the procedure with other developers, especially if a reverse proxy is required.

Thanks for providing a good service and library.