-
Notifications
You must be signed in to change notification settings - Fork 378
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
#424 plugins.json generated from metadata in tern.java #438
Conversation
Many thank's @paulvi! I would like to just know if the format for each plugin is OK or not. For instance I think we should have category field, perhaps support npm? Is homepage is OK, etc? |
Why doesn't |
I guess because each entry is not about a plugin, but supported technology first. Add @angelozerr For all currently absent fields like |
Please also compare with the most full variant https://github.com/paulvi/tern-plugins/blob/master/plugins.json It also has "dependencies"
https://github.com/paulvi/tern-plugins/blob/master/plugins.json#L187-196 |
Dependencies can be useful, I guess, when automating installation of a plugin. Is there a way for a tool to recognize which plugins are built into Tern itself, so that it won't try to install them? What is the process of installing these anyway? I still think we should standardize on |
Ok so many comments about this plugins.json descriptor and metadata. There are several problems with the generated plugins.json
"options": [
{
"name": "dontLoad",
"description": "Can be set to true to disable dynamic loading of required modules entirely,\nor to a regular expression to disable loading of files that match the expression.",
"type": "boolean"
}, options are used when tern plugin is configured (when it is download). In tern.java I use those information to provide an UI to customize the node plugin. So I think options should be removed from plugins.json
|
Please give json examples, or comment on paulvi/tern-plugins@ca6cdd4 or https://github.com/paulvi/tern-plugins/blob/ca6cdd499058ba50297f8f85c5fcf5d2f021f82b/plugins.json (as the most full option)
I think built-in plugin should appear, with
yep, dependencies are sure to be
Can we name dojotoolkit _1.6 as "plugin version file" ?
I suggested "pluginhomepage"
OK, category currently is absent event the most full variant
npm can install from url like GitHub or local folder,
"iconurl" Well, often is not not a plugin but technology/framework icon, |
why do you want to display requirejs, etc although you will not able to download it? Just to display in the list available plugin, that is it?
I think we should have simple JSON. So we should duplicate dojotoolkit to dojotoolkit_1.6, dojotoolkit_1.7, dojotoolkit_1.8.
With category you could categorize for instance cordovajs and tabris in the same category 'phone' for instance (not sure that it's a right name).
For me icon, is the same thing than metadata. It helps IDE to display options (metadata) and UI (icons) |
I'm not going to maintain a plugins.json file. I believe I've mentioned this in other discussions. Someone else can do that in a separate repository. |
plugins.json generated from metadata in tern.java
29 entries
see discussion in angelozerr/tern.java#190