feat(astro): Exposes extra APIs for script and testing #12052
+44
−21
Conversation
This file contains 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
🦋 Changeset detectedLatest commit: 0cd9fc0 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
matthewp
approved these changes
Sep 22, 2024
florian-lefebvre
approved these changes
Sep 28, 2024
bluwy
requested changes
Sep 29, 2024
Comment on lines
-43
to
+45
| * @internal only used for testing | ||
| * When building multiple projects in the same execution (e.g. during tests), disabling | ||
| * this option can greatly improve performance at the cost of some extra memory usage. | ||
| * |
There was a problem hiding this comment.
I'd prefer to keep this internal still. I imagine for external libraries this shouldn't have a significant impact if not used since it only mattered for Astro having tons of tests.
There was a problem hiding this comment.
Astro has around 2,000 tests. For companies requiring high reliability, it is not uncommon to have very exhaustive testing on libraries (at least for the companies I know that fit that description, including mine).
Multiple of our libraries for Next have over 10k tests each. Libraries for Astro (which we are working on) won't be any less tested.
There was a problem hiding this comment.
This isn't related to the number of test, but the number of builds for tests. Astro has many builds to test different permutations of all features and I doubt the same is needed for external libraries. Even so, Astro's test suite is due for some fixtures reduction because some fixtures could be combined, so in practice this option isn't really encouraged.
There was a problem hiding this comment.
It's been months, and we talked about this on the call in the meantime. Now that I've changed downstream packages, it seems the effects are the opposite of what I expected.
At the scale of Inox Tools, this indeed doesn't make much difference regarding performance. Initializing the compiler was a very small part of the test time. However, it does have a big difference in memory usage. Contrary to my expectations, it reduces memory usage by about 20% when tests have concurrency enabled.
Although it uses more memory as an overhead in later steps by not discarding the compiler, it actually saves memory overall. Without disabling teardown, tests running on the same isolate can discard the compiler while it's still in use by a different test, resulting in multiple instances of the compiler service existing in memory at the same time.
|
!preview test-apis |
|
Snapshots have been released for the following packages:
Publish LogBuild Log |
ascorbic
reviewed
Oct 8, 2024
ematipico
approved these changes
Oct 14, 2024
Co-authored-by: Matt Kane <[email protected]>
Should there be? 😅 |
|
@Fryuni what's the status of the PR? Considering this is a minor and we are exposing new APIs, I believe we should document them. Happy to help if needed. |
CodSpeed Performance ReportMerging #12052 will not alter performanceComparing Summary
|
Fryuni
added a commit
to Fryuni/inox-tools
that referenced
this pull request
Feb 14, 2025
|
Coming back to this PR (finally). I opened Fryuni/inox-tools#203 updating the Previously we talked about testing it out on the adapters repo, but since they are now part of this repo I don't think that would be necessary. |
|
Just reminding @Fryuni to loop me in re: what might be required for docs! Just because something wasn't documented before doesn't mean it shouldn't have been... 😄 |
sarah11918
reviewed
Feb 23, 2025
Co-authored-by: Sarah Rainsberger <[email protected]>
sarah11918
reviewed
Feb 25, 2025
|
|
||
| Fixes incorrect config update when calling `updateConfig` from `astro:build:setup` hook. | ||
|
|
||
| The function previously called a custom update config function made for merging an Astro config, Now it calls the appropriate `mergeConfig` utility exported by Vite that updates functional options correctly. |
There was a problem hiding this comment.
Suggested change
| The function previously called a custom update config function made for merging an Astro config, Now it calls the appropriate `mergeConfig` utility exported by Vite that updates functional options correctly. | |
| The function previously called a custom update config function made for merging an Astro config. Now it calls the appropriate `mergeConfig()` utility exported by Vite that updates functional options correctly. |
just nits!
sarah11918
reviewed
Feb 25, 2025
Comment on lines
+11
to
+12
| - `mergeConfig` allows users to merge partially defined Astro configurations on top of a base config while following the merge rules of `updateConfig` available for integrations; | ||
| - `validateConfig` allows users to validate that a given value is a valid Astro configuration and fills in default values as necessary; |
There was a problem hiding this comment.
Suggested change
| - `mergeConfig` allows users to merge partially defined Astro configurations on top of a base config while following the merge rules of `updateConfig` available for integrations; | |
| - `validateConfig` allows users to validate that a given value is a valid Astro configuration and fills in default values as necessary; | |
| - `mergeConfig()` allows users to merge partially defined Astro configurations on top of a base config while following the merge rules of `updateConfig()` available for integrations. | |
| - `validateConfig()` allows users to validate that a given value is a valid Astro configuration and fills in default values as necessary. | |
| These helpers are particularly useful for integration authors and for developers writing scripts that need to manipulate Astro configurations programmatically. |
nits!
Also, I like Matt's wording from the blog here!
sarah11918
reviewed
Feb 25, 2025
Comment on lines
+18
to
+19
| - `devOutput` (default `false`): output a development-based build similar to code transformed in `astro dev`; | ||
| - `teardownCompiler` (default `true`): teardown the compiler WASM instance after build. |
There was a problem hiding this comment.
Suggested change
| - `devOutput` (default `false`): output a development-based build similar to code transformed in `astro dev`; | |
| - `teardownCompiler` (default `true`): teardown the compiler WASM instance after build. | |
| - `devOutput` (default `false`): output a development-based build similar to code transformed in `astro dev`. | |
| - `teardownCompiler` (default `true`): teardown the compiler WASM instance after build. | |
| These options provide more control when running Astro builds programmatically, especially for testing scenarios or custom build pipelines. |
Same kind of nits/addition of blog post extra context!
sarah11918
approved these changes
Feb 25, 2025
There was a problem hiding this comment.
Approving for docs, with some nits below and additional "commentary" for your consideration @Fryuni ! I trust you to take it from here! 🫡
Also noting, to remind myself as much as anyone, I did not see any new error messages added to accompany this feature.
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.
Changes
Testing
There was no change in logic. The behavior for all changed functions was already tested.
Docs
buildAPI should be updatedastro/config, so nothing to update. The two functions newly exported would go in such a reference.