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

Non-Svelte imports trigger x will be treated as an HTML element warning #5712

Closed
madeleineostoja opened this issue Nov 23, 2020 · 10 comments · Fixed by #7826
Closed

Non-Svelte imports trigger x will be treated as an HTML element warning #5712

madeleineostoja opened this issue Nov 23, 2020 · 10 comments · Fixed by #7826

Comments

@madeleineostoja
Copy link

madeleineostoja commented Nov 23, 2020

Describe the bug
Importing a module with the same name as a HTML element causes Svelte to issue a warning about the element being treated as HTML unless it begins with a capital.

Logs
Example:

<section> will be treated as an HTML element unless it begins with a capital letter

To Reproduce
Import any module with the name of an HTML element, then use that HTML element in Svelte markup.

Eg:

<script>
  import { section } from '../styles/mixins.ts';
</script>

<section class={section}>
 ...
</section>

Expected behavior
Svelte should not issue warnings about HTML element usage if the module imported was not a Svelte component.

Information about your Svelte project:
System:
OS: macOS 11.0.1
CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
Memory: 549.42 MB / 16.00 GB
Shell: 5.7.1 - /usr/local/bin/zsh
Binaries:
Node: 12.6.0 - /usr/local/bin/node
Yarn: 1.22.4 - ~/.yarn/bin/yarn
npm: 6.9.0 - /usr/local/bin/npm
Browsers:
Chrome: 86.0.4240.198
Firefox: 74.0
Safari: 14.0.1
npmPackages:
svelte: ^3.17.3 => 3.29.0

Using Webpack

Severity
Merely annoying. Just adds extra console noise, no impact on usage at all.

@Conduitry
Copy link
Member

This came up before in #5570. I don't know what would be a better option for a reasonable heuristic for this warning.

@madeleineostoja
Copy link
Author

madeleineostoja commented Nov 24, 2020

Is the warning even that necessary? If it's getting triggered by simple use-cases like this I think it's more of a hinderance than a help in DX. At least providing a way to opt-out of it would be good. Because anyone coming from a JSX-like syntax will be familiar with needing uppercased components, and Svelte can (does?) document the need for uppercase components during the starter tutorial.

I know I was surprised to see the warning at all.

EDIT — I see you can disable the warning on a per-line basis with comments, but that seems clunky for something that IMO is flaky and unnecessary. Would be great if we could opt out at a global level, or just remove it entirely. Does the Svelte team have data on how common a problem it is to warn against?

@mattpilott
Copy link
Contributor

Screenshot 2020-12-19 at 9 12 52 pm
im being flagged for images, not too sure why

@peopledrivemecrazy
Copy link
Contributor

<a><img><div> are the ending tags on proper order?

@mattpilott
Copy link
Contributor

they are yes

@mattpilott
Copy link
Contributor

Ok so i'm a dope, there was a helper function called img 😅 which makes a heck of a lot more sense considering the warnings! (this message is mostly for my future self)

@al6x
Copy link

al6x commented Jun 8, 2021

Same bug. If the import commented out the warning dissapears.

Screen Shot 2021-06-08 at 11 34 30 pm

@feitzi
Copy link

feitzi commented Jan 24, 2022

Is there a solution available? My Svelte code is full of unnecessary warnings about valid html tags.

Example:

<form> will be treated as an HTML element unless it begins with a capital letter

@omer-g
Copy link

omer-g commented Feb 27, 2022

Is there a solution available? My Svelte code is full of unnecessary warnings about valid html tags.

Example:

<form> will be treated as an HTML element unless it begins with a capital letter

To avoid the warning one could import the library as such:

import * as sf from "svelte-forms";
sf.form(...);

@Conduitry
Copy link
Member

This should be fixed in 3.50.0.

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

Successfully merging a pull request may close this issue.

7 participants