shaneikennedy/npm.el

Support yarn

Opened this issue ยท 2 comments

This will need to be able to detect if a project is using yarn or npm for dependency management and provide the corresponding transient menus

An alternative would be to allow changing the underlying commands, this will make it easier to support any other package managers and I suspect this will make it easier to implement, eg:

(setq npm-install-command "yarn install")

This variables could be defined in the .dir-locals.el file to allow configuration per project

yeah, as you can see the issue has been open for a while ๐Ÿ˜“ I took an initial stab at this (what you mentioned above) a while back but the DX just wasn't good and the code got really complicated because all of the flags and command names aren't necessarily the same between npm and yarn (some differences in commands noted here). On top of that this issue was made basically right around the time yarn 3 (i think) came out and really switched up the conventions that were shared between npm and yarn.

Just as an example for why "yarn install" can't be used, as is, as a command prefix when adding new packages (obviously there are work-arounds this is just an example of how complexity keeps adding up if I wanted to support yarn in this package):

โฏ yarn install eslint
yarn install v1.22.19
info No lockfile found.
error `install` has been replaced with `add` to add new dependencies. Run "yarn add eslint" instead.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Command failed: node /Users/shane.kennedy/.yvm/versions/v1.22.19/bin/yarn.js install eslint

Another thing is discoverability when pressing M-x, if you're a yarn user it kinda sucks to have to make a mental map of the npm-named-command to what you actually want to do in yarn, and the findability when you're looking for a yarn emacs package but this package is named "npm.el".

Lots of subpar UX/DX things led me to two ideas:

  1. New emacs packages that contains both npm and yarn emacs funcationlity codebases, keeps them entirely seperate in terms of functionality and namespace, but ships them in one emacs package
  • Good because the code is clean and simple, good DX/UX, somewhat better findability when searching for packages than described above
  • Bad because it's essentially deprecating this repo, since any new work would be done on the new package, forces people to upgrade for no good reason (if you're just an npm user), really hard to think of a name for this package that would have good findability tbh
  1. Just fork this repo and make a yarn.el, update names and string constants for commands where necessary
  • I think this is the easiest and best way tbh, good UX/DX, good discoverability, good findability, simple code

But I never got around to either of these because I changed jobs and stopped working in javascript projects ๐Ÿ˜…

You're very welcome to take either of these options for yourself and publish packages based on this code ๐Ÿ‘