Skip to content
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

Webpack dashboard spawning Node.js visible terminal on Windows #212

Closed
cchamberlain opened this issue Oct 20, 2017 · 8 comments
Closed

Webpack dashboard spawning Node.js visible terminal on Windows #212

cchamberlain opened this issue Oct 20, 2017 · 8 comments
Labels
Milestone

Comments

@cchamberlain
Copy link

cchamberlain commented Oct 20, 2017

Please provide a description of the bug / issue, and provide the details below:

A second terminal window Node.js desktop terminal (never used this terminal) spawns when I run yarn run dashboard. Have tried many variations of the startup script and this always seems to happen.

I didn't see any mention of this in docs - if this is a normal thing just LMK and I'll submit a README.md PR.

====================================================================

If the issue is visual, please provide screenshots here

This is what I see. Same thing if I run with PowerShell:
image

====================================================================

Steps to reproduce the problem

Start webpack-dashboard via scripts (haven't tested outside of npm scripts).

====================================================================

Please provide a gist of relevant files
  1. package.json (specifically the script you are using to start the dashboard)

package.json relevant scripts - have tried putting this all in one script and doesn't change anything regardless of whether I use cross-env etc.

{
    "scripts": {
        "start": "cross-env NODE_ENV=development webpack-dev-server --colors",
        "dashboard": "webpack-dashboard -- cross-env USE_WEBPACK_DASHBOARD=true yarn start",
    }
}

This script gets the same results:

"dashboard": "cross-env-shell NODE_ENV=development USE_WEBPACK_DASHBOARD=true \"webpack-dashboard -- webpack-dev-server --colors\"",
  1. webpack.config.js

Can't post this but its using the default setup from the examples:

const DashboardPlugin = require("webpack-dashboard/plugin");

/* Some code runs here on startup that parses LESS files to ES6 modules and serializes them. No external processes involved, just an inline function that runs on startup */

module.exports = {
    /* normal stuff for a single config */
    plugins: [
        // Double terminal happens whether I put this here or at the end.
        !IS_PROD && USE_DASHBOARD ? new DashboardPlugin() : null,
        // awesome-typescript-loader async types checking
        opts.DISABLE_CHECKER ? null : new CheckerPlugin(),
        // Provide these as globals throughout webpack code (hack until these have been imported to all modules.
        new webpack.ProvidePlugin({
            "React": "react",
            "ReactDOM": "react-dom",
            "fetch": "isomorphic-fetch",
            "jQuery": "jquery",
            "$": "jquery",
            "window.jQuery": "jquery",
        }),
        new webpack.DefinePlugin({
            // Statically replace `process.env.NODE_ENV` with "production" or "development" to allow uglify to dead code eliminate
            "process.env.NODE_ENV": JSON.stringify(IS_PROD ? "production" : "development")
        }),
        IS_PROD ? new webpack.optimize.UglifyJsPlugin() : null,
        new ExtractTextPlugin({
            filename: "[name].css",
            // Extract from all chunks
            allChunks: true,
            // Only enable in prod so we can HMR in dev.
            disable: !IS_PROD
        }),
        // Generate a manifest file which contains a mapping of all asset filenames
        // to their corresponding output file so that tools can pick it up without
        // having to parse `index.html`.
        IS_PROD ? new (require("webpack-manifest-plugin"))({
            fileName: "asset-manifest.json",
        }) : null,
        // Generate a service worker script that will precache, and keep up to date,
        // the HTML & assets that are part of the Webpack build.
        IS_PROD ? new (require('sw-precache-webpack-plugin'))({
            /* configuration */
        }) : null,
        (IS_PROD || opts.DISABLE_SOURCE_MAPS) ? null : new webpack.SourceMapDevToolPlugin({
            //filename: "[file].map",
            exclude: ["manifest.js", "vendor.js"],
            columns: false,
            module: true
        }),
        IS_PROD ? null : new webpack.HotModuleReplacementPlugin(),
        IS_PROD ? null : new webpack.NamedModulesPlugin(),
        // Default locale in moment is en-US. This fixes known webpack errors.
        new webpack.ContextReplacementPlugin(/moment[\/\\]locale$/, /en.js/),
        // Extract all npm imports into a vendor.js chunk.
        new webpack.optimize.CommonsChunkPlugin({
            name: "vendor",
            // Auto move every resource from node_modules into the vendor bundle.
            minChunks: (module) => module.context && module.context.includes("node_modules")
        }),
        // Extract all remaining common code (the Webpack runtime) into a separate chunk. Ensures vendor.js does not change across releases.
        new webpack.optimize.CommonsChunkPlugin({
            name: "manifest",
            minChunks: Infinity
        })
    ].filter(x => x !== null);
}
  1. index.js (Your express based dev server, if applicable)

Just uses webpack-dev-server.

====================================================================

More Details
  • What operating system are you on?
    • Windows 10
  • What terminal application are you using?
    • hyper version 2.0.4. Also happens in PowerShell or if I enter cmd.
  • What version of webpack-dashboard are you using?
    • 1.0.0
  • What is the output of running echo $TERM?
    • echo $env:TERM: xterm-256color
@cchamberlain
Copy link
Author

More trial and error - I discovered that configuring via the "old" method and just running webpack-dev-server via yarn start does not spawn the additional node terminal. Not sure how long this method will be supported or if that clues you into where the problem lies, but using that for the moment.

@ryan-roemer
Copy link
Member

@carlospaelinck -- If you have a moment + PowerShell in a VM can you check this one out? (And we may need to request an actual respository + minimal reproduction steps for consistent diagnosis from @cchamberlain )

@cchamberlain
Copy link
Author

@ryan-roemer I'm assuming its environment related, but I'll try and get to testing against a create-react-app instantiated test soon.

@carloskelly13
Copy link

carloskelly13 commented Oct 23, 2017

@cchamberlain I have verified this. Now the window quickly disappears if you're not watching the project, but will remain for the lifetime of the webpack process. Not sure yet if it's a Node thing, webpack 3+ thing or inspectpack thing.

@cchamberlain
Copy link
Author

As a side note, I'll typically have to kill both processes after I shut it down.

@ryan-roemer
Copy link
Member

ryan-roemer commented Oct 26, 2017

@carlospaelinck @cchamberlain -- We could perhaps try https://github.com/pkrumins/node-tree-kill and process tracking which I've had good experiences with in the past if anyone has time to experiment as a solution to at least one aspect of the problem here...

@CoolGoose
Copy link

If i'm adding quiet: true to the devServer config it opens the second node process still, but there's no more output in it at least .

@parkerziegler
Copy link
Contributor

parkerziegler commented May 3, 2019

Hopefully this is closed out by #284. Per the Node docs:

On Windows, setting options.detached to true makes it possible for the child process to continue running after the parent exits. The child will have its own console window.

#284 adds a conditional OS check to set detached to false on Windows to prevent the spawned child process created by webpack-dashboard from opening its own console. This'll go out in v3.0.6.

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

No branches or pull requests

6 participants