algolia
boost already installed packages
Usually once you're busy writing an app, you reuse dependencies that you already use more often than adding new ones. Dependencies already in package.json should come earlier than ones you don't have installed yet.
I don't think that that will be possible with Algolia, but maybe we can check the ones in deps/devDeps and add them to a higher priority but not typo tolerant provider?
Yes, as a JavaScript dev here's what I expect:
local files (when starting with ./)
core modules
deps
devDeps
npm search
core modules, deps and devDeps can be matched using a simple http://fusejs.io/ for example.
Maybe deps and devDeps can be checked with the file path.
/src/ will have just deps /scripts/ will have devDeps, then deps / will have deps, then devDeps
We could check if it's a node or a browser script, and then show the core modules or not.
I think that currently we override default behaviour entirely (I forgot to double check that.) If we restore default behaviour and enhance it, then we can easily leverage multiple strategies.
Quick enhancement could be:
- re-enable default autocomplete suggestions in addition npm ones
- filter out already known packages from npm search
Maybe deps and devDeps can be checked with the file path. /src/ will have just deps /scripts/ will have devDeps, then deps / will have deps, then devDeps
I'm not a huge fan of this, because it won't be bullet proof.
Src is sometimes lib or in the root
scripts but alsoe tests or __tests__
We need more user feedback for this IMHO, even though I agree on the logic of boosting ;)
Regarding node core packages, it is also a tricky one given a user could be implementing a browser package, in which case he will want to use the non node package ones.
This will probably mean detecting or letting user decide on a project basis if the package is for node.
As for me, I am currently using https://atom.io/packages/autocomplete-modules.
We could also enhance this module to implement npm search and module install. Since it already have a lot of stars, community and handles local, core. One drawback is that it list dependencies inside node_modules which is not good since yarn and npm are flattening deps. You need to read package.json.
In any way, we either need to include those other features and face the community with the best require/import autocomplete or we enhance an already used module.
Regarding node core packages, it is also a tricky one given a user could be implementing a browser package, in which case he will want to use the non node package ones.
It's completely OK to require node core modules in browser packages, there should be no need of doing anything specific here. webpack and browserify are able to polyfill them.
It's completely OK to require node core modules in browser packages, there should be no need of doing anything specific here. webpack and browserify are able to polyfill them.
You don't want to suggestion to install deps that are node deps. Also you don't want to add those to your package.json.
Regarding the other plugins out there, ones are doing the installs, other are doing autocomplete but not both as far as we digged.
I think that leveraging autocomplete-modules for the locally installed packages can be a good idea and needs some tests. It should be a matter of disabling the hard override of the autocomplete suggestions.