-
Notifications
You must be signed in to change notification settings - Fork 751
fix(build): webviews sometimes did not load during development #6556
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Problem: In our development build we spawn a webpack server that serves the Vue files used by our webviews. It is served on port 8080, but sometimes an existing process is already using it, and this causes the webpack server to use the next available port. But because we assume it will use 8080 it silently breaks. Solution: Explicitly require 8080 in the webpack server cli command, also create a custom script to catch the error early and explain how to resolve it. Signed-off-by: nkomonen-amazon <[email protected]>
|
| "cwd": "${workspaceFolder}/../../packages/core" | ||
| } | ||
| }, | ||
| "presentation": { "panel": "dedicated" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This solved the following issue:
- The webpack serve command would fail
- A subsequent build task would reuse this terminal since it failed
- The reuse caused the port in use error message to be hidden
Now the webpack serve command is in a dedicated terminal that does not disappear, so it is more obvious when it breaks.
| "compileDev": "npm run compile -- --mode development", | ||
| "webpackDev": "webpack --mode development", | ||
| "serveVue": "webpack serve --config-name vue --mode development", | ||
| "serveVue": "ts-node ./scripts/build/checkServerPort.ts && webpack serve --port 8080 --config-name vue --mode development", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the explicitness just to make it easy to identify that the webpack port and the port in checkServerPort are easy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the explicit --port 8080 is a fallback in case something breaks in the script, but isn't explicitly needed. Also by default webpack serve will use 8080, so I thought it would just help make that more obvious.
) ## Problem: In our development build we spawn a webpack server that serves the Vue files used by our webviews. It is served on port 8080, but sometimes an existing process is already using it, and this causes the webpack server to use the next available port. But because we assume it will use 8080 it silently breaks, and when developing the Q webview would not load as expected. ## Solution: Explicitly require 8080 in the webpack server cli command, also create a custom script to catch the error early and explain how to resolve it. Now in the build tasks if 8080 is in use the dev can see the failed task with the solution explicitly stated. --- - Treat all work as PUBLIC. Private `feature/x` branches will not be squash-merged at release time. - Your code changes must meet the guidelines in [CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines). - License: I confirm that my contribution is made under the terms of the Apache 2.0 license. Signed-off-by: nkomonen-amazon <[email protected]>
Problem:
In our development build we spawn a webpack server that serves the Vue files used by our webviews. It is served on port 8080, but sometimes an existing process is already using it, and this causes the webpack server to use the next available port. But because we assume it will use 8080 it silently breaks, and when developing the Q webview would not load as expected.
Solution:
Explicitly require 8080 in the webpack server cli command, also create a custom script to catch the error early and explain how to resolve it.
Now in the build tasks if 8080 is in use the dev can see the failed task with the solution explicitly stated.
feature/xbranches will not be squash-merged at release time.