Conversation
Signed-off-by: arhimede <julian@dotkernel.com>
Member
Author
|
@GeorgeCatalinStan please confirm this |
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
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.
bundle-static-modules.mdandmanage-assets.mddocumented the same pipeline and contradicted each other — one said Vite andnpm run build, the other said the npm script copied images "as is". A reader who found the wrong one first got the 1.2.0 answer.They are now one page, kept at
manage-assets.mdso existing links keep working, retitled "Assets and the Vite build" in the nav. Three further findings are fixed in the merged text:viteStaticCopysends fonts topublic/fonts/but images topublic/images/app/. The old text said both were "copied as is", so a reader would writeasset('images/logo.png')and get a 404. There is now a source-to-destination table and anasset()example for each kind, matching what the shipped layout already does.package.jsondeclares^20.19.0 || >=22.12.0, and that is now what the page says.publiccleanup does not happen.emptyOutDir: truesits at the top level ofvite.config.jsinstead of underbuild, where Vite reads it, so it is ignored — andbuild.outDirlies outsideroot, which Vite will not empty without an explicit opt-in. The page now describes what the build actually does: it overwrites what it produces, stale files survive, delete the generated folders yourself if you need a clean result.The last point is an upstream bug in
dotkernel/lightas well, tracked separately; this page can be revisited once that is fixed.