* Make build exit with error code when interrupted
This addresses issue #1493.
Current behavior is that `npm run build` exits code 0 without creating a bundle when interrupted. This change makes the build script catch catchable interruptions and exit with the appropriate error code.
* Better error messages for kill signals
* Don't catch SIGINT
Ctrl+C should exit silently, and already produces a non-zero exit code when sent to the console while `npm run build` is running. Exit code 0 is produced if SIGINT is sent directly to the `node build.js` process, but this is unlikely to happen. A SIGINT handler in `build.js` will also be triggered by Ctrl+C in the console, potentially producing unnecessary noise.
* Style fix
* No changes needed to build.js
Problem is coming from the parent process, `react-scripts`
* Make react-scripts script handle signals
* Clarify context
* Add Advanced Configuration section
* Reference package.json instead
* Add HOST, HTTPS, and CI
* Switch wording from Amazon to a CDN
* Add test runner comment
* Add top-level README link
* Simplify wording
* Link to relevant docs
* Link to apps
* Add .env link
* Simpler links
* Add a CI flag note
* Fix paths in CSS files when homepage is set to "./"
In the production build, ExtractTextPlugin is used to generate a separate CSS file instead of injecting style through JavaScript. This plugin does not work well by default with nested output structure. To fix it, we give it a relative publicPath pointing to the build folder.
* Add section in README to explain how to make builds deployable anywhere
* Apply review requested change
* Apply review changes 2
* Make all vars accessiable in index.html
* Fix wrong env provieded to DefinePlugin
* Separate results from getClientEnvironment
* The `string` should be object instead of string
* Fix accessing wrong field
* Changed variables naming to `raw` and `stringified`
* Remove trailing commas
* Add ESLint config for VS Code users
* Update VSC ESLint note to a better solution
Update VSC ESLint note to a better solution as discussed in Pull Request
ATM if react-scripts is (erroneously) declared in `dependencies` instead of `devDependencies` or isn't declared at all, the `eject` script will fail half-way. This change makes it more robust, react-scripts will be removed from either, if present.
* Add causes of dev server not detecting changes
Add causes of `npm start` not detecting changes to Troubleshooting chapter of User Guide
* Reworded slightly
* Update README.md
* Use a more sophisticated template for end-to-end testing.
* Not publish integration tests to npm
* Use "commander" for cli argv handling
* Handle different scripts version forms and exits without a name given
* Prepare the commands for testing with a template
* Fix dev "template" path
* Add various features to test
* Test various features separately
* Test language features
* Comment unused e2e.sh lines
* Add "development" tests
* Test environment variables
* Test webpack plugins
* Replace kitchensink README
* Switch integration tests from jest to mocha
* Use `fs-extra`
* Use the correct folders
* Do some cleanup
* Print a better message for `--template`
* Test `npm start` with and without https
* Separate fast e2e testing from kitchensink testing
* Hide `--internal-testing-template` (former `--template`) CLI option
There’s a common tool included in Hadoop that also has a `yarn` command,
which created issues for users who had Hadoop installed:
* #1257
* #1363
Yarn also installs the command under `yarnpkg` alias (added in
cefa9a368d)
so we can use `yarnpkg` instead of `yarn` to make it more reliable.
This has no effect on users who don't have Hadoop installed, but those
who have won't see errors from falsely detecting Hadoop Yarn as Yarn
the package manager, and they can now also install Yarn to make use of
our Yarn support without the Hadoop Yarn interfering.
There’s a common tool included in Hadoop that also has a `yarn` command,
which created issues for users who had Hadoop installed:
* #1257
* #1363
Yarn also installs the command under `yarnpkg` alias (added in
cefa9a368d)
so we can use `yarnpkg` instead of `yarn` to make it more reliable.
This has no effect on users who don't have Hadoop installed, but those
who have won't see errors from falsely detecting Hadoop Yarn as Yarn
the package manager, and they can now also install Yarn to make use of
our Yarn support without the Hadoop Yarn interfering.
