Add a field for "elementVersion"?

[daattali]

I think it would be helpful to specify a version for the custom element. For example, if I add a few major properties/events to an element, I should be able to say that the element is now version 2.0.0

[justinfagnani]

The assumption so far is that this file is published with an NPM package and so the containing package version is the version for everything contained within.

Thinking about this a bit more, I think we should support cases where the manifest is not necessarily associated w/ a package.json (ie, if a bunch are bundled) and we should optionally support duplicating some of the package info, like name and version, in the Package interface.

[daattali]

While many (most?) custom elements built today do seem to be available as npm packages, I do think it's important to stay npm-agnostic and not assume/require that an npm package is created alongside the custom element.

[hsablonniere]

I think we should support cases where the manifest is not necessarily associated w/ a package.json

I think so too. If we take the devtools addon @Matsuuu is working on, there is a need for some browser based tools to know about the custom elements that are running without having to know they came from npm. The CEM could be referenced in the source like we do with sourcemaps for such cases.

[thepassle]

I wonder what the usecases are where we can have access to a custom-elements.json, but not a package.json.

It might be a bit double, but I do think it could be useful to have a version and even something like a packageName on the Package doc, which could be used to create URLs for things like unpkg, e.g. https://unpkg.com/${packageName}@${version}?module

[Matsuuu]

Something that I've grown accustomed to from the Vim/NeoVim scene is that each plugin is named by the repo it resides in.

e.g.
Plugin Matsuuu/pinkmare can be found in https://github.com/Matsuuu/pinkmare

So to expand on the idea @thepassle proposed, it would be really nice to be able to link a web component to the github repo it resides in, and maybe other sites like npm.

As for the implementation. I'm going to assume that a big portion or people run a analysis tool on a project with a package.json, and the package.json format has a repository -field. We could take it straight from there. Other cases could be that it could be given through a configuration file or a command line argument, and then appended to the manifest.

This could allow tooling / plugin developers to link the component to a external repository with ease.

---

An example use case for this could be the Developer Tools I'm working on. As a lot of sites using web components ship packaged by some tool, the source can be transpiled, minified, etc. But a user inspecting said page with Web Component DevTools might be interested in "How they created this component".

As the user inspects the component, if the developers included the repository url in the manifest, there would appear a link to the github repository, if not even the exact file, for the user to follow and see the actual implementation.

This would also help people find the actual implementation source for typescript components, which are transpiled by default.

[justinfagnani]

I agree with @thepassle. I think we could consider optional packageVersion and packageName fields for the entire manifest, but I don't think we should version individual declarations.