Preact-cli: Ejecting from preact-cli isn't very obvious or simple

[tmcw]

Do you want to request a feature or report a bug?

I'm requesting a feature.

What is the current behavior?

Right now, when you decide to implement webpack-dev-middleware or another more low-level integration with Webpack and Preact, the route to getting there is quite difficult to navigate.

If the current behavior is a bug, please provide the steps to reproduce.

• Try to switch away from preact-cli after starting to build an app in it
• The async! component syntax appears to be an in-built part of preact-cli, so the only option would be to copy & paste and move to your app
• Similarly the entry point is in preact-cli
• And the webpack configuration is abstracted to a level that it's hard to copy & paste or adapt it into another application.

What is the expected behavior?

This route would be documented and the niceities that preact-cli provides would be in modules that were usable outside of the module

If this is a feature request, what is motivation or use case for changing the behavior?

My process was:

• Using preact-cli, I eventually hit a level of complexity wrt proxying websockets, running a backend & frontend, and hitting problems with http-proxy, to the extent that I wanted out - to be able to run one server, one node application that both bundled and served routes.

Please mention other relevant information.

• node version
• npm version
• Operating system

[developit]

I would suggest this is a failing of the CLI, not of eject. Eject basically evaporates any value the CLI has over a boilerplate (updates, compartmentalization, reusability, etc).

Would the ability to invoke preact-cli programmatically and obtain a webpack configuration have helped avoid the wall you hit? Something like:

// webpack.config.js

module.exports = require('preact-cli').config({
  // options
});

[tmcw]

If preact-cli exposed a server that I could compose with an existing express server at the node level, that'd be ideal.

But also exposing the Webpack config would be a huge help - wrastling webpack is easily 80% of the yak-shaving here.

[developit]

Right now we recommend people do configuration via preact.config.js:

export default (config, env, helpers) => {
    env.ssr;  // Boolean indicating if this is the prerender config

    config;  // a standard webpack config!

    config.module.rules.push({
        test: /\.foo$/.
        use: 'foo-loader'
    });
};

[tmcw]

Yep, I was using that, it worked fairly well.

But eventually the indirection of proxying requests, and the flakiness of the proxy approach - how I'd need to configure the backend to listen on port 5000 but accept requests intended for 8080 (and embed links to 8080), how it distorts errors, wouldn't pass-through 400 responses, and so on - meant that I wanted to remove the proxy and use webpack-dev-middleware. Additionally, running frontend & backend servers means using something like concurrently to manage the dual processes.