(WIP) [Toolbox] Decouple the development environment

[jasonLaster]

Associated Issue: #1156

This is some preliminary work needed to get other tools to work with the local toolbox. This work came out of hacking on console.html while on the plane.

There are some high level pieces to look out for:

1. each tool has a bin/dev-server that uses the toolbox's dev-server
2. each tool has a configs directory
3. each tool has a webpack.config that uses the toolbox's config.
4. each tool is responsible for reading configs and then passing them along to services (server, tests, webpack config). This is a simpler system than before.
5. the toolbox index.js and client/index.js is tool agnostic. This includes the console passing in a dom element as root (not a react component).
6. I added some devtools-modules needed for the console

Screenshot

[jlongster]

Why not just do require("devtools-local-toolbox") ?

[rheesneb]

Help fix my duplicate account

[jasonLaster]

that's a confusing aspect at the moment.

The reason for this is that devtools-local-toolbox exports src/index.js not index.js

This will be cleaned up in a subsequent PR, but it's not related to the console working per se. The issue here is that the toolbox does 2 things:

1. It sets up a development environment - dev server and webpack config
2. It has a web app for the landing page and establishing the connection

The development environment does not belong in the web app's webpack bundle so it's in its own index. I'll move it to a separate package after this is done.

[jlongster]

I guess the main thing was referencing node_modules directly though: you should be able to do require("devtools-local-toolbox/index") right?

[jlongster]

I think it's a little confusing for code and configs to share the same directory. I'm still getting my head around this new structure so I don't know what to propose yet, but ideally the top-level config directory would just contain json files.

[Pomax]

also when using lodash in node code, it generally makes more sense to call the variable itself lodash, not _, since it's much for informative to grep for a full word string like lodash than it is to grep for a single character _ (especially with Node's ___filename and __dirname constants).

That said, most of what lodash does is covered by ES6+ these days, so that the only thing it's being used for in this code is covered by vanilla JS these days as Object.assign({}, envConfig, localConfig);

[jlongster]

@Pomax I agree. I've advocated for limiting our use of lodash. I would suggest removing it from this file as well.

[jasonLaster]

I think config.js in the top level would probably be fine.

I'm hesitant to move it into src or bin as those are different in my mind.

What do you think?

[jlongster]

This is src code so I don't see why src wouldn't make sense?

[jasonLaster]

i'm okay using ES6 where we can, but in this case, we do need a deep merge, so lodash.merge makes sense to me

[Pomax]

given the LTS status of 6.9, probably worth bumping this to >=6.9.0