psychollama / further.vim Goto Github PK
View Code? Open in Web Editor NEW:flashlight: Follow JavaScript imports to their source
License: MIT License
:flashlight: Follow JavaScript imports to their source
License: MIT License
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.
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.
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.
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.
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.
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.
node_modules
(why), then look for libraries there instead of node_modules/node_modules
.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.
library/dist/index.js
:
node_modules
library
package.json (main: 'dist/')
dist
package.json (main: 'entry.js')
entry.js
index.js
require('library/dist')
should resolve library/dist/entry.js
)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')
Sometimes module names or relative paths are inside json files, such as package.json
. Might as well enable further
in that filetype.
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).
Allow the user to select the follow path via visual mode.
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".
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.