electron-webpack-dashboard icon indicating copy to clipboard operation
electron-webpack-dashboard copied to clipboard

npm package

Open phra opened this issue 6 years ago • 10 comments

hi,

congrats for the new dashboard!

it would be nice to have this project as a npm package in order to simplify the installation step.

are you considering it or are there some problems that block the publishing?

thanks.

phra avatar Aug 23 '17 10:08 phra

how would that work?

kenwheeler avatar Aug 23 '17 12:08 kenwheeler

actually i don't know.. i will investigate if it's possibile! one solution can be to distribute directly the binaries and make a js wrapper to manage the execution..

phra avatar Aug 23 '17 12:08 phra

I tried this out locally by building the project on my Mac, launching the .app file, then starting up another project with the webpack-dashboard plugin added. I think this could be published to npm like so:

Create a package for each platform, e.g. electron-webpack-dashboard-darwin, electron-webpack-dashboard-win32, electron-webpack-dashboard-linux. Each of these packages contains only the binaries for the associated platform, with a definition in its package.json limiting the os. e.g.:

{
  "name": "electron-webpack-dashboard-darwin",
  "version": "1.0.0",
  "os" : ["darwin"]
}

Then, create a main package called electron-webpack-dashboard which lists all of the platform packages as optional dependencies, along with a bin to spawn the right binary for the right platform:

{
  "name": "electron-webpack-dashboard",
  "version": "1.0.0",
  "bin": "bin/electron-webpack-dashboard",
  "optionalDependencies": {
    "electron-webpack-dashboard-darwin": "^1.0.0",
    "electron-webpack-dashboard-win32": "^1.0.0",
    "electron-webpack-dashboard-linux": "^1.0.0"
  }
}
#! /usr/bin/env node
const { spawn } = require('child_process');
const { platform } = process;
let child;

if (platform === 'darwin') {
  child = spawn(pathToMacApp, { detached: true });
} else if (platform === 'win32') {
  child = spawn(pathToWinApp, { detached: true });
} else {
  child = spawn(pathToLinuxApp, { detached: true });
}

child.unref();

Then users could install this and launch it from a package script:

{
  "name": "my-app",
  "scripts": {
    "start": "electron-webpack-dashboard && webpack"
  },
  "devDependencies": {
    "electron-webpack-dashboard": "^1.0.0",
    "webpack-dashboard": "^1.0.0"
  }
}

Does that make sense?

eliperelman avatar Oct 28 '17 21:10 eliperelman

i think that there is room for improvement:

  1. you are starting the dashboard process but you are not closing it after
  2. to solve 1. and to have a seamless integration i suggest to wrap also the executable of webpack so that "start": "electron-webpack-dashboard" can be enough.

what do you think? @kenwheeler @eliperelman

phra avatar Oct 29 '17 14:10 phra

Performing 2 would completely destroy my use case which is to allow it to be used from other webpack wrappers, like Neutrino.

Since my goal is to manage the lifecycle of the electron process within my own webpack wrappers, 1 is not a concern for me either. Better to keep the implementation flexible rather than lock users into a webpack abstraction that doesn't do anything else right now.

eliperelman avatar Oct 29 '17 14:10 eliperelman

since your use case sounds like an advanced one i suggest to default to 2. and via a flag disable the webpack lifecycle management like --no-webpack to let the developer manage it. what do you think?

phra avatar Oct 29 '17 16:10 phra

If you go down the road of wrapping webpack, you put a much higher maintenance burden on this library to keep webpack and its apis up to date, as well as making sure to support all its CLI features. In my opinion, it's just coupling this too much and expanding the scope of this tool far beyond its original use.

My vote is neither 1 nor 2.

eliperelman avatar Oct 29 '17 16:10 eliperelman

not implementing 1. means that the execution of npm start is not idempotent. 2. should be implemented via a flag or a default behaviour in order to easily give a nice dev experience via the npm package. (i.e. without giving a kill command at every restart and stop)

phra avatar Oct 30 '17 00:10 phra

Would really appreciate this

Polyterative avatar Dec 11 '17 08:12 Polyterative

Why couldn't this be a plugin for webpack, much like the current one, but launch a secondary server that loads this app?

From the source code it looks like most of the code is just a react app, with a little bit of Electron specific stuff. If that can be separated it seems like this would be very easy, although I don't know how the electron app and the dashboard plugin interact.

@kenwheeler is this a possibility?

NickBolles avatar Sep 28 '18 16:09 NickBolles