forked from angular/angular-cli
-
Notifications
You must be signed in to change notification settings - Fork 0
Create a new pull request by comparing changes across two branches #1135
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
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…r-sync` is not installed Running the SSR dev server when `browser-sync` is not installed would print the error, but then build the browser and server targets, then hang and never return control to the user until they manually Ctrl+C. This change skips building at all if `browser-sync` is not installed, immediately returning control to the user. This is a simple workaround, but there are two deeper bugs which would benefit from investigation: 1. Figure out why NPM sometimes doesn't install `browser-sync`. It was happening inconsistently for me when running `ng add @angular/ssr`. 2. Figure out why Architect does not cancel/await targets still executing when a builder completes.
The component stylesheet HMR functionality requires build-time analysis of each component by the AOT compiler to provide the needed information to identify initial styles and detect individual changes to each style. Part of the style HMR rebuild logic was unintentionally enabled in JIT mode. The initial load of the application operated correctly but subsequent changes to file-based stylesheets were delayed by one rebuild cycle. To avoid this misalignment, all component stylesheet HMR functionality is now disabled when in JIT mode.
… `browser` builder The new routing APIs don't support `browser` builder, but calling `ng add @angular/ssr` with a `browser` builder would still prompt the user to add them. If the user said "Yes", it would actually ignore that answer and not enable the new APIs. With this change, `ng add @angular/ssr` when using `browser` builder does not show the prompt and assumes the answer is "No". It also throws an error if the user runs `ng add @angular/ssr --server-routing`. I'm not aware of a built-in prompting mechanism in schematics beyond `x-prompt`, which can't be used here, so instead I just called Inquirer directly. Unfortunately testing the prompt is a little awkward, as Inquirier does not provide useful APIs in this space. I evaluated `@inquirer/testing`, but ultimately decided that was more intended for testing custom Inquirer prompts, not mocking usage of standard prompts. Schematics APIs do not provide a useful way to inject additional data like a mock, so instead I had to do this through a `setPrompterForTestOnly` function. I'm not a huge fan of it, but I don't see a more straightforward way of solving the problem.
… route when the app router is empty
Adjusts the server assets to use the original content length Closes #28832
Updated function to support handling `baseHref` starting with './' path correctly.
…e template HMR The Angular AOT compilation logic for a rebuild has been updated to include infrastructure for additional checks of stale TypeScript files against updated files. The actual comparison aspects have not yet been implement and no behavior changes are yet present for template HMR.
Ensure that errors occurring during initialization are properly propagated, as Piscina currently swallows errors during worker initialization. For more details, see: https://github.com/piscinajs/piscina/blob/b64747233446ca4271e6aed744a740f637e278a5/src/worker.ts#L57
This commit introduces end-to-end (e2e) tests to validate the server-side rendering (SSR) setup.
The `stylePreprocessorOptions` were ignored, meaning that `silenceDeprecations`, for example, was not used when building tests.
…thm name Stackblitz appears to fail when attempting to use `crypto.createHash` with an algorithm value of `sha-256`. Since Node.js supports both the hyphenated and unhyphenated values, the later is now used to avoid issues when running on Stackblitz.
…router config This commit ensures proper handling of nested redirects that are implicitly structured but not explicitly defined in the router configuration. Closes #28903
Set up the initial workflow to build upon.
The SSR router relies on wildcard matching rather than params. This commit refactors the stored routes by removing the `:params`.
Update the perf workflow to the latest version to allow for uploading results to database
…n from angular core using application whenStable function instead of custom util function from angular core.
`resolve/test/list-exports/packages/tests/fixtures/resolve-2/project/test/resolver/multirepo/package.json` is not a true postinstall script
…extraction This commit fixes an issue where the components where still being boostrapped when using `provideAppInitializer` Closes #29131
Currently the interop resulting target of a `ts_project` ends up not necessarily working at runtime. This may be the case because a consuming Node program may end up with mixes of `node_modules` dependencies from `rules_nodejs` (old) and `rules_js` (new). This sounds fine at first glance, but in practice can break very subtly because: * Rules NodeJS leverages the linker, creating `node_module` directories outside of Bazel, at runtime. These don't depend on symlink resolving. * Rules JS puts real node module folders via Bazel actions. These rely on `pnpm` non-hoisting layout, and symlink resolving. As we can see there is a hard conflict with symlinks. They need to be enabled with the new toolchain, but the other one doesn't enable symlink resolution, and enabling is not possible as we'd otherwise risk escaping the sandbox and cause even more subtle errors. A good compromise solution is to automatically drop the `rules_js` node module files/folder in the interop-`rules_nodejs` target and instead brining in the equivalent `@npm//` dependencies from `rules_nodejs`. This kind of keeps the logic similar to when not using `rules_js` or the interop, and enables the simplest & safest mental model; and it works compared to other solutions I tried with symlinking. Notably, we can't keep both node module variants as the linker doesn't override existing node module files from e.g. rules_js then (and would break then).
This commit updates `build_angular` to the `rules_js` ts_project rule. Notably a few real type issues surfaced but previously didn't surface due to some unknown resolution issues that resulted in `never` types; where every possible value was assignable; so this change improves type safety and a TODO was left for the "brittle code fragment".
This reverts commit 3af88fe. No longer needed because the interop lays out the node modules directory like without the interop & `ts_project` migration; so the chunk name changed back to what it was before. Good news.
Node.js workers will currently fail to initialize if the `execArgv` option is used and it contains v8 specific options. This is currently problematic for the JS transformer worker because it contains a workaround to remove the SSR `--import` argument that is used to add a loader hook for SSR purposes. The filtering of the argument and subsequent use of the `execArgv` array had the potential to pass custom Node.js options to the worker and cause it to fail. These options can be passed by developers on the command line when invoking the Angular CLI. To mitigate this problem, the `execArgv` option is now only filtered and used if the SSR import argument is present in the array. Otherwise, no value is passed which allows the default Node.js behavior to be used. While this does not fully solve the problem for all projects, it does remove the problem from non-SSR projects.
Set the mnemonic to determine if it allows us to reduce the number of RBE queries executed
This reverts commit d17174b.
We should only force the type for files that we know are JavaScript. Otherwise we risk breaking the magic type detection done by Karma. The previous code broke for `jasmine.css`. Fixes #29190
The `@ngtools/webpack` package has been migrated to the `rules_js` ts_project rule. Other than the `index.ts` addition, no code changes were needed.
The `@angular-devkit/build-webpack` package has been migrated to the `rules_js` ts_project rule.
Migrates `@angular-devkit/core` to `ts_project`.
The `@angular/create` package has been migrated to the `rules_js` ts_project rule.
The `modules/testing/builder` target used for builder integration testing has been migrated to the `rules_js` ts_project rule.
The `@schematics/angular` package has been migrated to the `rules_js` ts_project rule.
The `@angular-devkit/schematics-cli` package has been migrated to the `rules_js` ts_project rule.
The `@angular/cli` package has been migrated to the `rules_js` ts_project rule.
The `@angular/pwa` package has been migrated to the `rules_js` ts_project rule.
This commit migrates `@angular/build` to `ts_project`.
The E2E tests have been migrated to the `rules_js` ts_project rule.
797f480
into
angular-indonesia:master
9 of 11 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Checklist
Please check to confirm your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information