Project Handover

[MeirionHughes]

I'm afraid it is unlikely I'll be able to get back into this - I have several other projects I'm also struggling to find time for. Unfortunately, I'm not using this in my work either. I have neither an excuse / a need to improve it nor the time. :/

It should be clear to anyone that the rework branch work was arriving at a point where I was reinventing a loader system in order to account for Aurelia (at the time) having 3 separate ways to load dependencies (webpack, systemjs, requirejs). I came to the conclusion that the best solution would be to simply have all of this linting stuff done as a webpack plugin - that way the dependency resolution would be handled for me and this project could just focus on linting. A bridge too far and I lost the enthusiasm.

I suspect the vscode plugin is in far better shape / more useful than this project anyway. In the unlikely case that any of this code is still useful, I'll be happy to transfer it and/or transfer ownership of the npm package names if they are wanted.

@EisenbergEffect

[atsu85]

Sad news, but understandable.
When i was doing FE development, i found it to be most useful Aurelia related tool - at that time VS code plugin wasn't even available, so i can't really compare these two (never used VS Code either).
@eriklieben, perhaps you could shed some light on the common and distinct linting related features of aurelia-template-lint vs Aurelia VSCode Extension. It would be fantastic, if VSCode extension could be refactored into "framework service" (like TypeScript language service), that could be consumed by Aurelia plugins for any IDE (or build tool for only linting purposes), not just for VSCode.

@MeirionHughes, thanks for sharing this fantastic tool!

[EisenbergEffect]

@MeirionHughes We're greatful for all the work you put into this. Let's hear from @eriklieben to see how he sees this with respect to the VS Code plugin. We'll probably end up accepting ownership of this in one way or another. I'd like to get Erik's thoughts.

[eriklieben]

Thank you for all the work you put into this!

To answer the questions above:

The visual studio code extension has a language server and a language client part; this is something which the vs code team created to create decoupled components that can be reused. So, in theory, we should be able to, for example, create a new client in SublimeText and reuse the same server language server. Except for some parts that are specific to the vs code editor that are currently in the language server client (for example: the custom view that currently gives Aurelia HTML syntax information).

I've recently moved over the validations that were in the client language server part of the extension to the server part and did some refactoring to make creating validations easier. What we can do is migrate the current code to the vs code validations. And if there are any typescript validations move them to a TypeScript language service extension, so they can directly be reused in every editor that talks to TypeScript.

Or we can leave it as it is, and try to integrate it, but that might require parsing files once in the vs code extension and once in the lint tool.

I am currently also fighting a bit to find the time and first want to finish the intellisence/ smart autocomplete first. After that, I want to dive into this and get it better integrated or migrated.

Maybe we can fork or move the lint tool to the Aurelia GitHub, so we can find ways to provide support for it.

[EisenbergEffect]

@MeirionHughes Do you want to just transfer this to the aurelia GitHub org? We can take the repo and then update the readme to indicate that we're going to work most of these ideas into the VS Code plugin. Thoughts?

[MeirionHughes]

@EisenbergEffect can do; seems I can't transfer unless you give me permission on Aurelia to make repositories; or I transfer directly to you?

[EisenbergEffect]

I'll take it into my personal account and then move it to Aurelia. Thanks!

[Alexander-Taran]

can be closed