Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
2 tasks done
shuuuuun opened this issue May 2, 2022 · 5 comments
Closed
2 tasks done

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

shuuuuun opened this issue May 2, 2022 · 5 comments

Comments

@shuuuuun
Copy link

shuuuuun commented May 2, 2022

Before you submit:

  • Please search through the existing issues to see if your feature has already been discussed.
  • 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

Thank you.

@sherwinski
Copy link
Contributor

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
Copy link
Author

shuuuuun commented May 7, 2022

@sherwinski Thanks for your reply!

My use case is as follows.

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
Copy link
Contributor

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
Copy link
Contributor

sherwinski commented Jun 27, 2022

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.

@sherwinski sherwinski closed this as not planned Won't fix, can't repro, duplicate, stale Jun 27, 2022
@shuuuuun
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants