Comments (6)
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.
from custom-elements-manifest.
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.
from custom-elements-manifest.
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.
from custom-elements-manifest.
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
from custom-elements-manifest.
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.
from custom-elements-manifest.
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.
from custom-elements-manifest.
Related Issues (20)
- Generated schema contains errors HOT 3
- How to output `oneOf` for discriminated unions. HOT 1
- sync between source and manifest HOT 2
- Add support for package and element icons and screenshots HOT 1
- add funding links
- Add support for CSS CustomState
- Add support for symbol-named class members HOT 1
- Add support for including canonical URLs for References
- Needed styles for elements HOT 4
- Package name field HOT 1
- Ability to document type of detail property for CustomEvents HOT 5
- README should mention that manifest can (and should) be generated by a tool
- `tagName` should not be part of the manifest HOT 4
- Publish New Version HOT 1
- Access modifier issue on derived class HOT 1
- Status of the "manifest" HOT 4
- Deomnstration Project using the Manifest... HOT 1
- To which files should the manifest link. .ts, .js, both, ... HOT 8
- componentRegistered Information HOT 1
- desc.startsWith is not a function HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from custom-elements-manifest.