Giter VIP home page Giter VIP logo

further.vim's Introduction

Hey

I'm a web developer that's really into peer-to-peer systems, NixOS, and anything related to Vim. My joy in life is finding force multipliers, the lesser-known tools and paradigms that make you more powerful. You can find my recommendations here.

Live FOSS or die ๐Ÿค˜

further.vim's People

Contributors

psychollama avatar taylor1791 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

Forkers

novusnota-forks

further.vim's Issues

Optionally resolve symlinks

Yarn workspaces use symlinks in node_modules to reference other packages in the monorepo. If you open those files with further, your resolved file path will be inside node_modules. That can cause issues with other plugins (e.g. triggering linter ignore patterns).

Automatically resolve symlinks and expose an option to disable it.

Support root (tilde-based) imports

There's a babel plugin that transforms imports like ~/some/file.js into ../../some/file.js based on your file's current position relative to the root. It's useful in deeply nested file structures.

Though I'm not a fan, I've found myself working in a codebase which religiously uses the plugin, and further doesn't work for any of it (with the exception of normal npm packages).

Either I should add first class support for the plugin, or I should add a more powerful interceptor pattern. I'm leaning towards a better interceptor pattern.

Support line numbers in file paths

I haven't implemented mappings that check for line numbers after the file path simply because it's not a common pattern in JavaScript. Recently I noticed someone using further with ag output, which looks a bit like this:

src/utils/prefetch.js:5: * @return {Promise<void>} - Resolves after successfully caching.
src/resolvers/scene.js:2:import resolveLight from './light';
src/resolvers/scene.js:26:    return this._lights.map(id => resolveLight({ id }, context, info));

That's ideal output for gF and <c-w>gF and a really good excuse to write more vimscript.

Add mappings for splits

It seems there are more mappings that need to be mapped. <C-w>f opens the file in a horizontal split.

See this Stack Overflow for more mappings (though I think the others can be composed).

Support module builtins

On startup, grab the set of all module builtins like events and http. New modules like http2 are added in newer versions, so a hard-coded list can easily fall out of date. Something like this is probably fine:

let modules = system('node -p "JSON.stringify(require(''module'').builtinModules)"')
let modules = json_decode(modules)

When the developer tries to open one of these builtins, open it in a read-only buffer:

enew
let source = systemlist('node -p "process.binding(''natives'')[''' . module . ''']"')
call setline(1, source)
setf javascript

Some kind of warning is probably appropriate, like "Warning: viewing read-only module builtin".

Support package.exports (native modules)

As of this writing, I've only encountered it once in the wild. It was the multiformats package. It adds a brand new layer of complexity to resolving modules by defining an exports map that defines what consumers can actually import. Those imports aren't necessarily real file paths and may have layers of resolution rules of their own, depending on postinstall hooks or compilation variables.

Node documentation: https://nodejs.org/api/packages.html
Webpack documentation: https://webpack.js.org/guides/package-exports/

further.vim should support the standard.

Tooling is a little immature at the moment so I might delay the implementation until things settle.

Add test coverage

Being one of my earliest vim plugins, I hadn't learned to properly test vimscript yet. I've developed better habits in newer plugins. The lack of test coverage and uncomfortable complexity has dissuaded me from making meaningful changes. I should bite the bullet and add coverage before #17 becomes a priority.

Add support for JSON

Sometimes module names or relative paths are inside json files, such as package.json. Might as well enable further in that filetype.

Node module resolution differences

There are some subtle differences between Further's module resolution implementation and Node's. It's pretty unlikely that anyone will find 'em, but still, probably best to keep 'em consistent.

  • If your current directory is node_modules (why), then look for libraries there instead of node_modules/node_modules.
  • Relative directory imports should check for a package.json (e.g. require('../library') where library is a directory with a package.json file). If people notice this, it's probably because they're doing naughty things in a monorepo.
    • Danger: not all directories should be treated as possible modules. For example, this should resolve to library/dist/index.js:
      node_modules
        library
          package.json (main: 'dist/')
          dist
            package.json (main: 'entry.js')
            entry.js
            index.js
      
    • More danger: module-relative paths should still consider directories to be possible modules (e.g. require('library/dist') should resolve library/dist/entry.js)

Expose programmatic API

Expose the resolver functions as a public API. Specifically, expose the initialization function so other file types can be explicitly registered by the user (lookin' at you, html).

These are the specific functions I'm looking to expose:

  • further#Initialize()
  • further#Resolve('some-package-name')

Find implicit jsx imports

Hello,

further.vim do not find .jsx files when not explicitely specified in path. E.g.

import  { foo } from './bar';

where ./bar refers to ./bar.jsx will fail with Can't find module "./bar".

I did not find any config that would allow it, but I may have missed it.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.