Hi,
currently it is rather a „hack in“ than a „hook in“ or plugin, since I have to patch the built ternWorkerCore and _javascript_Plugin files, because I know of no other way :)
1) Can I use that with the CodeEditWidget and if yes, where do I have to put the .definition folder?
2) I don’t really setup „custom completions“, I just add my (dynamic) Tern definition file into the built ternWorkerCore file (in the ternDefaults definition, like ecma5, ecma6, chai). So nothing too complicated. Let’s say I succeed in adding my type definitions via 1) (see my example file from the last email), then I could activate the code completion for my types simply by adding /* eslint-env mydefinition */, right? So the only feature missing for my needs would be „Turning of filtering based on eslint-env“, as you said. Do I understand that correctly?
3) Again, I don’t setup a custom ESLint validation, I just patch the ESLint globals (see eslint/conf/environments) in the built ternWorkerCore file so that my custom types appear as builtin types, just as String or Date are. Otherwise a new MyType1() would give me red squiggles.
I hope that makes it clearer.
Regards Sebastian
Your plugin adds 1) Type definitions for
Tern 2) Custom completions and 3) ESLint validation? 1) We have limited support already for
adding type definitions. See Bug 484833 https://bugs.eclipse.org/bugs/show_bug.cgi?id=4848332) Custom completions would require
a new Tern plugin that contributes on the 'completions' request. We
would like to support third party Tern plugins, though at the moment we
are focused on fetching type definitions for your code (creating or finding
an index for some node module you are using). I was pretty sure we
had a bug for this, but I don't see one, so feel free to create one. Turning
off the filtering based on eslint-env will be one step towards this. The
only thing holding us back from that change is that projects without a
.tern-project entry would get all of our templates showing up in content
assist all the time.3) We haven't set up a way to contribute
to our ESLint setup so I would be interested in how you are hooking in.
Adding new rules shouldn't be difficult but when setting up the configuration
for ESLint we are doing lookups in Orion's preference service as well as
looking at eslintrc files.CurtisFrom:
Sebastian Pahnke <pahnke.sebastian@xxxxxxxxx>To:
Orion developer discussions
<orion-dev@xxxxxxxxxxx>Date:
05/04/2016 02:55 AMSubject:
[orion-dev]
Custom Types/Globals in CodeEditWidgetSent by:
orion-dev-bounces@xxxxxxxxxxx Hi,
to use the CodeEditWidget and its completion/validation features with my
own custom types, I currently have to do the following steps (which currently
work fine for me):
1. In ternWorkerCore.js search for the ternDefaults definition and add
a link to my ASP.NET HTTP request handler (e.g. TypeHandler.ashx?return=types)
to the dependencies list => this loads the code completion definitions
for Tern
2. In ternWorkerCore.js search for eslint/conf/environments and add a link
to my request handler (e.g. TypeHandler.ashx?return=globals) which extends
the builtin globals by my types => ESLint knows my types WITHOUT having
to specify a eslint-env directive
3. In _javascript_Plugin.js search for ecma5 in the computeContentAssist
function and add the name of my type definition file (e.g. mydefinition:
true)
The mentioned request handler dynamically creates the Tern definitions
/ ESLint globals for the custom types (see below for example outputs),
because they can possibly change due to a plugin concept. Therefore a static
definition file is not sufficient.
But this procedure is tedious and error prone especially when I update
the widget, since the mentioned files are minified by default(!). To figure
out the steps above I actually created a custom build definition which
omits the minification step.
With all the new possibilities due to .tern-project files, is there an
easier way to accomplish this? Ideally I would like to write some kind
of plugin file where I setup all I need and then just feed it to the CodeEditWidget
by a function/during the create step. The important points for me are: 1. A dynamic HTTP request handler has to work, a static definition file
is not sufficient 2. The types should behave like builtins without the need to specify a
eslint-env directive in every script
TypeHandler.ashx?return=types returns a Tern definition file like this: define([], function () {
return {
"!name":
"mydefinition",
MyType1:
{
...
}
}; });
TypeHandler.ashx?return=globals returns ESLint globals like this (extending
the predefined builtins!): define(["eslint/conf/globals"], function (globals) {
globals.builtin.MyType1 = false;
...
return { builtin: globals.builtin }; });
Thanks and regards, Sebastian
_______________________________________________ orion-dev mailing list orion-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________ orion-dev mailing list orion-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/orion-dev
|