Bug 496655

Comment 1 Michael Rennie 2017-01-10 15:39:12 EST

Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see:

https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04002.html

Comment 2 Sebastian Pahnke 2017-03-01 07:14:09 EST

This is still relevant. Without it, tern plugins can not be loaded in the CodeEditWidget use case without modifying the minified ternWorkerCore.js file.

Comment 3 Remy Suen 2017-03-01 07:15:50 EST

(In reply to Sebastian Pahnke from comment #2)
> This is still relevant. Without it, tern plugins can not be loaded in the
> CodeEditWidget use case without modifying the minified ternWorkerCore.js
> file.

Reopening. Thanks for letting us know your interest in this bug, Sebastian.

Comment 4 Steve Northover 2017-03-29 18:10:51 EDT

It is unlikely we will get to this.  Are you blocked?

Comment 5 Sebastian Pahnke 2017-03-30 01:05:41 EDT

I'm not blocked. It's just inconvenient having to edit the minified file to get my Tern plugin to be loaded.

Comment 6 Steve Northover 2017-03-30 08:45:03 EDT

Mike, is there anything simple we can do to help here?

Comment 7 Michael Rennie 2017-03-30 12:41:02 EDT

(In reply to Steve Northover from comment #6)
> Mike, is there anything simple we can do to help here?

I'd have to investigate again now that we have the idea of a project context that finds  / loads files. 

If I recall the last time I looked into this, there was a problem with requiring arbitrary scripts...

Comment 8 Michael Rennie 2017-05-10 11:02:17 EDT

Pushed fix to:

https://github.com/eclipse/orion.client/commit/f174862a0b708ab3c49d7a887a1f037dea851137

We can now load plugins from the workspace or from a hosted location.

A few things to note:
1. plugins must use an AMD or UMD header.
2. to reference tern or infer, the path must be "tern/lib/tern" and "tern/lib/infer" respectively
3. plugins can listen to all signals and passes as they normally would - but the JS tools do not provide a method for plugins to report back to / interact with the Orion UI in any way.
4. to load a plugin you have to give it a location in the .tern-project file AND the name in the .tern-project file has to match the plugin name that is registered in plugin source. For example:

{
	"plugins": {
		"always-yes": {
			"location": ".tern-plugins/always-yes.js" 
		}
	},
	"libs": [
		"ecma5",
		"ecma6"
	],
	"ecmaVersion": 6
}

5. To load a plugin from a hosted site (from a URL - not the workspace), the location must be the full URL to the plugin source. For example http://plugin-host.orion.eclipse.org:9000/always-yes.js
6. To load a plugin from the workspace, the location must point to the plugin source which must reside in the .tern-plugins folder

I will attach a test project that includes a contributed plugin as an example.

Comment 9 Michael Rennie 2017-07-12 16:23:42 EDT

Created attachment 269335 [details]
Example project

Here is the example project I forgot to attach.

It has a plugin that gets loaded and contributes to content assist.

It also demonstrates:
1. loading a definition file from the workspace
2. recovery of loading a bad definition (incorrect syntax)
3. all of the passes and signals a tern plugin can contribute to