Skip to content

Change allowReferrer to requireNoopener #571

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

Closed
2 tasks done
benmccann opened this issue Aug 23, 2023 · 11 comments
Closed
2 tasks done

Change allowReferrer to requireNoopener #571

benmccann opened this issue Aug 23, 2023 · 11 comments

Comments

@benmccann
Copy link
Member

benmccann commented Aug 23, 2023

Before You File a Bug Report Please Confirm You Have Done The Following...

  • I have tried restarting my IDE and the issue persists.
  • I have updated to the latest version of the packages.

What version of ESLint are you using?

any

What version of eslint-plugin-svelte are you using?

any

What did you do?

melt-ui/melt-ui#443 (comment)

rel="noreferrer"

What did you expect to happen?

rel="noreferrer" should not warn unless using svelte's legacy compiler option. We need a way to configure that

sveltejs/svelte#8230

What actually happened?

warned

Link to GitHub Repo with Minimal Reproducible Example

simply add rel="noreferrer". if you need a reproduction I can provide

Additional comments

No response

@ota-meshi
Copy link
Member

It looks to me like you're using the svelte/no-target-blank rule yourself. Turn off rules when not needed 😉

https://sveltejs.github.io/eslint-plugin-svelte/rules/no-target-blank/

@benmccann
Copy link
Member Author

oh, you are right! i'm sorry for this report. thank you so much for the help

@benmccann benmccann reopened this Aug 24, 2023
@benmccann benmccann changed the title noopener should only be required when compiling with the legacy option Change allowReferrer to requireNoopener Aug 24, 2023
@benmccann
Copy link
Member Author

benmccann commented Aug 24, 2023

Thanks for the earlier advice. We tried to configure https://sveltejs.github.io/eslint-plugin-svelte/rules/no-target-blank/ appropriately, but were unable to do so (melt-ui/melt-ui#443 (comment)). I think the allowReferrer option isn't exactly correct because it allows you to write rel="noopener" when I think what you need to write is rel="noreferrer". We should probably replace the allowReferrer option with a requireNoopener option

@ota-meshi
Copy link
Member

For clarity, could you please provide code examples of how the new option works and the correct and incorrect code when using the option?

By the way, the rule option is based on rule implemented for JSX.

https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/jsx-no-target-blank.md

Copy link
Contributor

github-actions bot commented Nov 3, 2023

This issue is is stale because it missing information and has been open for 60 days with no activity.

@mcmxcdev
Copy link

mcmxcdev commented Nov 3, 2023

Still relevant

Copy link
Contributor

github-actions bot commented Jan 3, 2024

This issue is is stale because it missing information and has been open for 60 days with no activity.

@github-actions github-actions bot added the Stale label Jan 3, 2024
@mcmxcdev
Copy link

mcmxcdev commented Jan 3, 2024

Still relevant

@JounQin
Copy link
Collaborator

JounQin commented Jan 3, 2024

@mcmxcdev Please help to answer @ota-meshi's question instead of posting meaningless comments?

@mcmxcdev
Copy link

mcmxcdev commented Jan 3, 2024

The rule currently requires the user to write rel="noreferrer noopener" although only rel="noreferrer" should be necessary. That would mean that the allowReferrer option (false by default) should actually be called requireNoopener and be true by default.

You can find additional context on melt-ui/melt-ui#443 (comment) and sveltejs/svelte#6289 (comment)

@benmccann
Copy link
Member Author

Sorry for missing that there was a question here.

I just spent the past hour and a half reading though a bunch of related issues on this to referesh my memory of this issue and provide clarification and realized there are no code changes required here and that my request was driven by a pair of misunderstandings, so I will close this issue. I do think some doc updates would be very helpful as I really badly misunderstood this rule in multiple ways and it seems likely that @mcmxcdev had some misunderstanding as well, so I sent #656 to address that.

Thank you for maintaining this great plugin!

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

No branches or pull requests

4 participants