can't run dist

[gooddaddy]

1.yarn build
2.cd ./dist
3.node server.js

Error: ENOENT: no such file or directory, open '/Users/bobo/Documents/bobo/demoCode/reactQlDemo/firstreactql/dist/dist/manifest.json'

What has many dist in path?

[leebenson]

The intended way to run the server is from the root project folder, with:

npm run server

That's because the path names are resolved during webpack compilation relative to where the paths are at the time of compilation.

I'll leave this issue open because it would be good to have dist work as a standalone folder that can moved around without the original source tree.

[david-potgieter]

Also experiencing issues with the build:

1. yarn build
2. yarn server
3. Go to: http://localhost:4000
4. Error: Error Browser history needs a DOM

[leebenson]

@david-potgieter - I'm not able to reproduce that issue, in either the JS or Typescript versions of the current kit.

Did you change kit/entry/browser.js at all, or any of the source code anywhere else in the kit?

Does the same thing happen with a fresh reactql new project?

[david-potgieter]

@leebenson indeed - working fine with a fresh install.

• I have not changed kit/entry/browser.js at all - but have changed src.app.js and wrapped src.app.js with a <Switch> component. Will debug a little more and see if I can get it to work.

[leebenson]

@david-potgieter - if you want to post your full app.js file here, I'll check it out too.

[leebenson]

On reflection, I don't think having a static dist file that can be moved around is realistic. There are a few downsides:

1. Warnings are generated in Webpack for NPM mods that use iconv-loader and other source code that doesn't conform to our loader structure; it's too easy to hit edge cases. Suppressing those issues typically involves re-writing the loading styles of third-party mods, which can get hairy/fragile to maintain.

2. The resulting server.js currently weighs in at a slim 28kb on Node 7.6+. The majority of code is external and has already been built in node_modules, so there's no point in transpiling stuff where the work has already been done. Building server.js as a bundle adds 2.5mb+ disk space to what is already available at ../node_modules.

3. If you use any NPM mod that requires C/C++ extensions, that stuff will fail if it's not available in the node_modules tree.

4. It's much easier to build a Docker image if you extend from a ready-made Node base, compile modules locally with npm i off of the available package.json, and run the server with npm run server vs. running a pre-compiled server.js via 'bare' Node. babel-preset-env will use the local Dockerised environment to polyfill the local Dockerised requirements, so you can guarantee it will work alongside your installed Node version. Otherwise, server.js is not guaranteed to be portable.

The those reasons, I'd like to keep the official recommendation to upload the full source tree to your hosting environment, alongside the native npm run build... commands and npm run server to invoke.

Doing it any other way is not portable.