psychollama / further.vim Goto Github PK

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

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)

Allow the user to select the follow path via visual mode.

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.

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.

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.

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".

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.

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.

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).

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.

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')