Add a template for creating web component custom element

[vemonet]

SolidJS is a really good framework to quickly build and publish standard web components as custom elements that can be reused from any other framework, but there are currently no templates to help doing so. All current templates are only about creating websites

To get started creating a new custom element with SolidJS to be published it takes a bit of research and work that can be a bit tedious:

• Figuring out how to define a custom element in solid from https://github.com/solidjs/solid/blob/main/packages/solid-element (there aren't much docs about building and publishing custom elements in the official docs)
• Adding all the required metadata for proper publication
• Configuring typescript to generate type declaration files
• Configuring eslint and prettier

This simple template shows a complete web component <my-counter initial-count="1"> with all required tools and metadata preconfigured

It uses light DOM and have an attribute in order to show off a bit all features used when defining a component

For the compilation target I used esnext like for the other templates, but I am wondering if es2015 would not be better to recommend for compatibility?

@amoutonbrady @ryansolid @birkskyum

[birkskyum]

@vemonet , regarding the compile target. For this pr it's correct to maintain esnext, like you already do, so it's identical to the other templates, but feel free to elaborate on your compatibility concern in a new issue ticket if you think it's best to change this across all templates.

[vemonet]

I am not a complete expert on this topic, but as I understand it:

• es2015 would be more stable, and more compatible with older system (e.g. people who don't update their browser)
• esnext gives access to newer features, smaller bundle size, and better performance overall

esnext is usually implemented by the main browsers latest versions (firefox, chrome, safari), but it evolves with time, so there's not 100% guarantee it will work in every environment at all points in time (e.g. testing environments)

I guess for 99.9% of the cases esnext would be better. And one could argue people should have their browser up-to-date anyway, so we are doing them a favor if we force them to update it

[titoBouzout]

It looks fine to me, tested it and works as expected. My only suggestion would be to also add the typings for the custom element, so in case it's used in JSX it won't trigger type errors. I think something in the lines of the following would be enough (this doesn't seem to give type errors)

const [read, write] = createSignal(9);

interface MyCounter {
  'initial-count': number;
}

declare module 'solid-js' {
  namespace JSX {
    interface IntrinsicElements {
      'my-counter': MyCounter;
    }
  }
}

export function Test() {
  return <my-counter initial-count={read()}/>;
}

/cc @atilafassina