Project-Based Autocompletion

NOTE: This blog post is a work in progress

TL;DR: Update everyone's autocompletion/editors by updating package.json

Observation:

Recently, Javascript DX has seen a rising trend. This can be seen with tooling, such as Flow/Typescript, Webpack, ESLint, and others. These tools significantly improve our productivity. But there is one area of DX that hasn't seen much improvement over the years, and that is, and that is Autocompletion.


Here are a number of significant issues with autocompletion that I face on a daily basis.

  1. Encourage and Disallow Conventions:
    Sa you're contributing to a project that embraces functional programming styles. In this case, it wouldn't make sense for editors to suggest a try/catch statement. Instead, they should encourage patterns that match the conventions of the project.
  2. Migration Between Projects With Different Code Styles:
    Autocompletion is suitable only if you contribute to a projects with the exact same code style, and that's highly unlikely. Contributing to projects of different conventions deteriorates your productivity as a developer if your snippets do not match the conventions of the project.
  3. Snippets Sharing Between Editors:
    There were a number of cases where I wanted to use 'x' snippet for 'y' editor because I use 'z' editor. A much more elegant solution for this is to create a single snippet library that can be used by all editors.
  4. Snippets can be updated like npm packages, this will make the process of updating snippets much faster
  5. Lack of scoping: Say I change from the front-end to a backend node project. Do i still want react snippets when typing in a node backend? This would be fixed by installing snippets per project. If the app contains both node and front-end react code, which is pretty common, scopes of plugins can be limited to specific folders.

Solution:

Create non-editor specific snippets, transform them (ex. add/remove semicolons), and return a list of possible suggestions.

Here's a rough example that explains the idea:
1. Allow Plugins (in this case Flowtype and ES6 Snippet Library) to return lists of snippets.
2. Those suggestions will then be prioritized according a project configuration file. For example, typing ``
3. Plugins can extend each other (like ESLint configs)

// @NOTE: `+` denotes 'extends'
(Flowtype Suggestions + ES6 Snippet Library + Other Snippet Libraries)
    -> Prioritize
    -> Conform to Project Specific Conventions
    -> Return Snippet Suggestions

Challenges:

As a user of a library, I want a level of consistency between projects. For example, when I press p in one project, I should be able to switch to another project and get very similar list of suggestions. Pressing p in one project might return the following:

'p' snippet suggestions example:

p -> Promise snippet  
pe -> process.exit snippet  
pr -> prototype snippet  

If I switch to another project, pressing p shouldn't return prototype. In other words, there needs to be a way of enforcing consistency between project snippet key-mappings. If this wasn't the case, adding project-specific autocompletion might make us less productive. A possible solution to this is to prevent conflicts of packages at install time. Another possible solution is to create a base configuration that has a short list of key-mappings, like in the previous "'p' snippet suggestions example" that are should either be remove instead of from being overridden.

// @NOTE: `+` denotes 'extends'
(
 BASE_SUGGESTIONS +
 Flowtype Suggestions +
 ES6 Snippet Library +
 Other Snippet Libraries
)
    -> Prioritize
    -> Conform to Project Specific Conventions
    -> Return Snippet Suggestions

Amila Welihinda

Curious fellow and a wonderer of things. Creator of Fertona

Fremont, CA

Subscribe to Open Sourcery

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!