Consider a new name

[justinfagnani]

"custom-elements.json" is a filename and not necessarily a description of the file's contents or purpose. The file specific name also might not be required to be custom-elements.json. On npm it could be referenced from a package.json field, like the "types" field. In other systems, like databases, the name might not matter or even exist.

A few options to consider:

• Custom elements manifest
• Custom elements docs file
• Package docs file

Considering that the format will be capable of pretty fully describing package contents, being a "package docs file" might make sense. There very well might be other communities interested in shared docs infrastructure, even if that isn't a primary goal right now.

[thepassle]

I personally dont mind the fact that its a filename, but I'd be interested to hear some more thoughts/opinions here.

I could see it be called custom elements manifest, manifest seems to be "popular" (manifest.json, precache manifest, etc) i could see custom elements manifest "fit in" perhaps a bit better.

[bennypowers]

Consider: in the docs for web app manifest, MDN recommends the filename manifest.webmanifest.

[justinfagnani]

I like the name "Custom Elements Manifest". The filename would presumably still usually be custom-elements.json though we should also standardize a package.json field to point to the manifest so that indexers can see that a package has a manifest without having to unpack the entire tarfile.

[thepassle]

I like the name "Custom Elements Manifest". The filename would presumably still usually be custom-elements.json t

sounds fine to me 👍

[daKmoR]

without having to unpack the entire tarfile.

yeah that's a huge pain-point.

So we could have something like this in the package.json?

"custom-elements-manifest": "./custom-elements.json"

[LarsDenBakker]

Manifest sounds good to me.

[hsablonniere]

I like manifest too 👍

[jorenbroekema]

Manifest sounds good to me too!

[Westbrook]

I also think that manifest sounds good here.

Not to spend too much time in the bikeshed, but to compare to similarly relevant art, I would submit https://github.com/AdobeXD/design-system-package-dsp#understanding-the-dsp.json-file (not that I worked on this, even though I work at Adobe). The idea of a "Design System Package" could nicely pair with the idea of a "Custom Element Package" long term (as it hints at the ability to scale up to larger amounts of support documentation/files/etc. and the possibility of things in the "package" beyond just definitions, e.g. CSS module scripts to apply to self or parents or share, JSON module scripts, image/font assets, etc), and also points a bit to the conversation around the "Web Packaging Format" https://github.com/WICG/webpackage.

However, don't stop moving forward on my account as Manifest support much (or likely all) of the context referenced by the "Package" context as well.

[abdonrd]

Manifest sounds good to me too!

[Niznikr]

Manifest works for me!

[justinfagnani]

Sounds like consensus to me :)

[blikblum]

without having to unpack the entire tarfile.

yeah that's a huge pain-point.

So we could have something like this in the package.json?

"custom-elements-manifest": "./custom-elements.json"

I would use camelCase to keep consistency with other fields

 "customElementsManifest": "./custom-elements.json"

[justinfagnani]

Lets discuss the name in #29