Doom-emacs: Enhancing the JavaScript lang module.

[orther]

I've been working heavily on a large JavaScript project and slowly changing the provided doom lang/javascript module. I've broken things a lot but am really starting to feel stable. if you are open to changes in the JS module I'd like to clean things up and create pull request? I have added a lot of functionality that I do think some people will want but not all. So it would make sense to make certain features option but live within the lang/javascript module. So my questions are:

1. Are you open to changes to the JS module?
2. Is there an idiomatic way for modules to have opt-in functionality? (e.g. enabling jest test runner support, enabling automatic code format on save)

Before I refactor these our of my own private module I want to make sure it is something you and/or other people would want. Below is a list of what I've added and have been using.

What I've Added

Most of these are fully working but some clean organizing is needed:

• Auto Format Code: eslint w/ prettier
• Running tests w/ Jest or Mocha for current buffer or current project using mocha.el
  
  
  
  • NOTE: If I can enable RealGUD (I saw you disabled it a few months back) interactive debugging works for Jest and Mocha.
  
  
• Add {project-root}/node_module/.bin/ to path so locally installed binaries are used.
• Use eslint_d if available otherwise fallback to eslint
• Flow type suppport w/ company mode integration.
• Code coverage visual overlay to easily see what is being tested using coverlay.el

[hlissner]

That'd be fantastic. I'd happily welcome all those changes.

As for opt-in functionality, take a look at def-project-mode!. It lets you define project-specific minor modes. Here's an example from the javascript module:

(def-project-mode! +javascript-npm-mode
  :modes (html-mode css-mode web-mode js2-mode markdown-mode)
  :files "package.json")

This minor mode would only activate in html/css/web/js2/markdown-mode buffers AND when package.json is present in the project root.

This gives you the ability to have (among other things) project-specific...

• keybindings (attach to +javascript-npm-mode-map)
• snippets or file templates (in a +javascript-npm-mode folder in your yasnippet snippets / the file templates module)
• hooks (+javascript-npm-mode-hook)

These modes can also be activated through .dir-locals.el, wherein you set doom-project to the name of the project mode you want to activate.

Presumably, you could create jest/mocha/tape/anything project minor modes, and attach your custom functionality to it. Is that what you're looking for?

[orther]

def-project-mode is what I've wanted without knowing it. That should make things a lot cleaner. I like the extensibility without coupling. I'll start to work on this over the next few days. I'll come back if I have any questions.

I'm thinking I'll get things working without the interactive debugging that relies on RealGUD in this effort. I'll tackle that in another issue/pull. I rather focus on getting the other features working with the project modes.

Thanks for the feedback.

[orther]

NOTE: I have some of this work done locally but haven't been able to work on it due to unexpected non-dev work (business/admin stuff) I had to hop on. I will be back sometime next week and hope to get this done shortly after that.

[orther]

STATUS UPDATE: Just want to touch base so you know this isn't abandoned. I have recently ran into issues with my current flow setup that causes CPU and Memory usage to go insane. I have disabled flow-minor-mode just to get work done. I plan to track down what is causing this and finally push the flow support.

[jamestthompson3]

@orther Any updates on this?

[orther]

@jamestthompson3 me and my team stopped using flow so I ended up removing that from my config. The other items I just haven't taken the time to move to the javascript module. I am in the middle of trying to get Indium working with mocha.el (which I "patched" to work with Jest) for step debugging. After I get that working I'll try to a pull request together.

If you're looking for Flow support I could likely add that back in but need more people to test and help make sure it's solid.

[jamestthompson3]

I've got flow working in my fork. I have some ideas for improving the JS lang support in general. I've added a function that adds the project node_modules to emacs' exec path, that way tools like eslint, prettier, flow, etc. will always be run from the directory binary, not the global version. I also have removed tern in favor of tide which gives more detailed code info and doesn't require users to add another dependency to their package.json or install tern globally. I would be happy to collaborate with you in making the JS module better and incorporate some of the more popular front-end tools.

[hlissner]

@jamestthompson3 Wait, tide works with javascript? I thought it was only for typescript. Does it offer code completion for JS too?

[jamestthompson3]

@hlissner Yes, tide works with javascript. It works ok out of the box, but even better if you add a jsconfig.json file to your project root. It also offers completion through company-tide

[hlissner]

@jamestthompson3 I'm unhappy with tern and would love any opportunity to replace it. I'll give tide a try.

[orther]

Tide does look nice. Somewhere along the way I got the impression tide wouldn't be compatible with my needs but I can't specifically remember why.

One problem that first comes to mind is if tide has the same limitations as VSCode (which I believe it does because it uses tsserver), module resolution is determined through static analysis only. This results in no way to to support dynamic module imports during compile time such as webpack's require.context.

Honestly the level of functionality tsserver provides has had me consider just not using dynamic imports. Not sure it's a good decisions to limit the defacto JS support to it though.

I'll confirm dynamic module imports are an issue and report my findings. It may be worthwhile to look for limitations vscode users complain about for JS (non-TypeScript) development to determine if they'll be an issue for us.

[mandarvaze]

develop branch seems to have some tide integration.
See https://github.com/hlissner/doom-emacs/tree/develop/modules/lang/javascript

[i-oliva]

Hi @orther, may I ask where can I find your configuration for step debugging?

[hackeryarn]

@jamestthompson3 Would you mind sharing your setup for getting binaries fromnode_modules to run? I specifically can't get eslint to run from my node_modules.

[hlissner]

@hackeryarn The lang/javascript module on the develop branch should use local installs of eslint in your project. Is that not the case?

[hackeryarn]

flycheck doesn't pickup eslint from node_modules.

Originally I thought this was an issue with projectile. However, even after resolving all the projectile issues, this one still persists.

[hlissner]

@hackeryarn could you create a new issue for that, with your M-x doom/info in it? This is certainly a bug.

[hackeryarn]

@hlissner done https://github.com/hlissner/doom-emacs/issues/798

[jamestthompson3]

@hackeryarn here is my javascript section, it works well on the develop branch.