Skip to content

IDE integration #222

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
use-strict opened this issue Jul 22, 2015 · 9 comments
Closed

IDE integration #222

use-strict opened this issue Jul 22, 2015 · 9 comments

Comments

@use-strict
Copy link

My goal is to have seamless integration with insert_favorite_IDE_here while developing. This means having the compilation errors exposed and mapped to file/line/col in the IDE. I have achieved this to some degree, at the cost of having to hack the dev server, which is less than ideal to say the least.

I will explain what I tried and hope you can help me find a solution that would fit with the existing use cases, so I can get rid of this hack.

First attempt:
  • Use webpack Node.JS API with 'watch' option (performance is v. bad without watch)
  • Get the errors after each compile, format them nicely and spit them out to the console.
  • Add labels for compilation start/end events.

This worked like a charm with VSCode, without having to hack webpack or webpack-dev-server in any way. However, this means I cannot benefit from the dev-server features. Also, this doesn't work with PHPStorm/WebStorm, because its file watchers are supposed to execute on every save and it can't keep a single instance running in the background.

Second attempt:
  • Use dev-server to do the build.
  • Add another HTTP route that spits out compilation errors (for the last compilation). This should work because the request is delayed until there is no pending compilation.
  • Extract useful info about the errors and output them as JSON. Have another "client" script that connects from CLI over HTTP and formats them for the IDE to consume. This script is called from PHPStorm/other IDE.
Problems:
  • Knowing what exactly to collect from the error objects. For instance, the location (line/col) is found differently per type of error. I need to make sure that every error has a file path, line, column and message.
  • dev-server uses the middleware which keeps bundles in memory. This should be ideal, but due to some limitations (current environment setup complexity, legacy app), I have to rely on serving the files from disk (at least for now). Something like this was already proposed in the middleware thread, but it was rejected at some point, probably because it didn't seem a valid use case.

I'm linking the commit which contains the changes that I made to the dev-server. This doesn't include the actual formatting of the errors or the client script.
use-strict@3f58f60

I found no clean way of exporting/serializing the errors (which are also circular objects) other than nitpicking each bit of information.

What are your thoughts on this?

@SpaceK33z
Copy link
Member

Hey @use-strict. It's been a while, but I see you've started working on a webpack-runner tool to help accomplish this. I think it's outside the scope of webpack-dev-server to implement this, but I'm happy to help or make sure the right hooks are added in webpack-dev-server or webpack-dev-middleware.

@use-strict
Copy link
Author

My original post is still relevant. If you have a look at the webpack-runner tool, inside error-formatter file you will see I did lots of hacky reverse engineering on the webpack errors. I used properties that were available, yet undocumented. While this works, it may break at any time when updating webpack.

To summarize:

  1. Normalized errors are something that should be fixed in both webpack and dev server.
  2. Should be able to output to disk as well instead of memory. See use-strict@3f58f60#diff-83c4482ab4d62154c877147880243858
  3. Reporting the errors via HTTP route: use-strict@3f58f60#diff-15fb51940da53816af13330d8ce69b4e

If this makes sense, we can split this issue into three separate issues. I don't know why I did everything in a single commit, that was a mistake on my part.

@SpaceK33z
Copy link
Member

  1. The next release of webpack-dev-middleware will contain a reporter option, which allows you to hook into the errors. See Reporter option webpack-dev-middleware#91 for more info. I think you could use that to normalize the errors.
  2. Is this really necessary? Maybe you could use write-file-webpack-plugin for this?
  3. Would it be possible to hook into the setup option of dev-server and add the route there?

Generally, I'd like to only provide the hooks necessary for you, so your tool can do the job / formatting.

@use-strict
Copy link
Author

The next release of webpack-dev-middleware will contain a reporter option.

I'm using the webpack node API. That's the primary concern. dev-server is just a bonus, but I'm thinking a fix for one should also fix the other.

Is this really necessary? Maybe you could use write-file-webpack-plugin for this?

That plugin could work. I didn't know of its existence. I will test it out.

Would it be possible to hook into the setup option of dev-server and add the route there?

I couldn't find a way to hook into the dev-server from CLI. Much of the options logic is in the CLI entry js file so requiring something directly from dev-server would mean duplicating logic.

@SpaceK33z
Copy link
Member

I'm using the webpack node API. That's the primary concern. dev-server is just a bonus, but I'm thinking a fix for one should also fix the other.

The reporter option also works with dev-server. Note that I just released webpack-dev-middleware@1.7.0, which contains this option.

I couldn't find a way to hook into the dev-server from CLI. Much of the options logic is in the CLI entry js file so requiring something directly from dev-server would mean duplicating logic.

Ah, I thought you would be starting the dev-server only from the Node API. From the CLI you can still use the setup option, but it has to be in the webpack config file (devServer.setup). A somewhat hacky solution would be to do it like this:

var webpackRunner = require('webpack-runner');

module.exports = {
    ...
    devServer: {
        setup: webpackRunner
    }
}

@use-strict
Copy link
Author

The reporter option also works with dev-server. Note that I just released webpack-dev-middleware@1.7.0, which contains this option.

I mean webpack, not webpack-dev-server node API:

webpack(config, (e, stats) => {
    // process stats.compilation.errors
});

Can this reporter option be specified via webpack.config ?

From the CLI you can still use the setup option, but it has to be in the webpack config file (devServer.setup).

Thanks, I will try and see if it works.

@SpaceK33z
Copy link
Member

SpaceK33z commented Sep 10, 2016

Can this reporter option be specified via webpack.config ?

At the moment, no. But isn't that outside the scope of your package? It's meant for development, right? If you want that functionality you'd need to make a PR in the webpack repo.

@use-strict
Copy link
Author

If you want that functionality you'd need to make a PR in the webpack repo.

Will do that. As far as the dev-server goes, I will check if that reporter functionality works for me. Thanks for the tips.

My webpack-runner module is only filling in for the missing reporter functionality in webpack. It's not necessarily for development and it's not using the dev-server. For dev-server integration I had a separate CLI tool that connected to that HTTP route I showed you and redirected output to the console. I didn't publish it because it only worked with a hacked dev-server. If the error hooks work, I will try to adapt it.

@SpaceK33z
Copy link
Member

Ah okay, missed that. I'm going to close this now since there are no specific issues here. If you need specific hooks, feel free to create an issue for them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants