feat: template based init script #3524
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
Migrated template system from .tmpl extensions to real file extensions
with unified __VAR__ substitution syntax (previously {{VAR}}).
Changes:
- Updated substitution regex in src/utils.ts to use __VAR__ format
- Modified src/init.ts to process all text files instead of only .tmpl
- Renamed all .tmpl files to use actual extensions (.ts, .tsx, .json)
- Updated all template files to use __VAR__ syntax
- Updated tests to reflect new syntax and file extensions
- Updated DESIGN.md with new conventions
Benefits:
- Proper syntax highlighting in all template files
- Editor auto-formatting and type checking now work
- Simpler processing logic without special extension handling
- Consistent variable syntax across all file types
All 45 tests passing.
marvinhagemeister
pushed a commit
that referenced
this pull request
Oct 6, 2025
This fixes issues I have with running tests on one of my servers, where port 8000 on `localhost` is occupied. Note: The current `init` test will continue to fail, but that will hopefully get replaced by #3524 which does not have this problem. Before: ``` [ "error: Uncaught (in promise) AddrInUse: Address already in use (os error 98)", " at listen (ext:deno_net/01_net.js:594:35)", " at serveInner (ext:deno_http/00_serve.ts:675:16)", " at Object.serve (ext:deno_http/00_serve.ts:591:10)", " at ext:deno_http/00_serve.ts:819:10", " at ext:runtime_main/js/99_main.js:708:13", " at eventLoopTick (ext:core/01_core.js:179:7)" ] [...] Builder - write prod routePattern => ./packages/fresh/src/dev/builder_test.ts:284:6 Builder - file:// islands => ./packages/fresh/src/dev/builder_test.ts:319:6 Builder - serves static files in subdir in prod => ./packages/fresh/src/dev/builder_test.ts:474:6 init - can start built project => ./packages/init/src/init_test.ts:237:6 FAILED | 471 passed (14 steps) | 4 failed | 18 ignored ``` After: ``` ok | 475 passed (14 steps) | 0 failed | 18 ignored ```
marvinhagemeister
added a commit
that referenced
this pull request
Oct 6, 2025
This reverts commit 198816b.
marvinhagemeister
added a commit
that referenced
this pull request
Oct 6, 2025
This reverts commit 198816b.
marvinhagemeister
added a commit
that referenced
this pull request
Oct 6, 2025
#3524 unfortunately introduced a regression in the init script which breaks it. This was caused by two independent problems: 1. Only files reachable in the module graph are published, meaning the templates itself weren't published to JSR 2. When publishing to JSR all specifiers become `https://` internally which breaks doing path operations like `path.resolve()`, `path.relative()` and all others. This is something that cannot be tested locally in advance Addressing these is going to require a bit of work. The quickest way to get init working again is to revert it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Supersedes earlier attempt -> #3517
This is now ready for review.
The major upside and motivation for this template based approach is that it is now possible to view what gets generated in the repository as actual valid files including syntax highlighting and formatting.
Previously those files where just strings inside the old
initscript, which is IMHO a nightmare for maintainability.The approach for this template system is loosely based on Vite's
create-vite, which also includes (redundant) templates inside the repository, see here -> https://github.com/vitejs/vite/tree/main/packages/create-viteIncluded in the tests are compatibility checks against the current
@fresh/[email protected], those can get removed at a later point when the templates start to diverge. They are only included for demonstration purposes, that this new implementation generates 100% identical output.This means that the first PR after this got included, which modifies the templates so the output differs from the old
initscript, also needs to include:Since this is a rather large PR, it may be more approachable to view the branch directly -> https://github.com/fry69/fresh/tree/fry69/refactor-init-template-rename/packages/init
Generated PR message below:
Replaces inline string-based project generation with file-based templates for improved maintainability and extensibility.
Architecture
Template structure:
assets/template/- Complete project templates (vite, vite-tailwind, builder, builder-tailwind)assets/variants/- Additive overlays (docker, vscode, vscode-tailwind)assets/base/- Common files synced across template variantsTemplates use
__VARIABLE__syntax for substitution (project name, dependency versions). Files with__prefix are renamed to.prefix during generation (e.g.,__gitignore→ .gitignore).Template selection logic:
Maintenance workflow
Edit shared files in
assets/base/vite/orassets/base/builder/, then rundeno task syncto propagate changes to template variants. Template-specific files (deno.json, vite.config.ts, styles.css) are never overwritten.Version resolution
Matches existing behavior: only Fresh core version is fetched from JSR, all other dependencies use fixed versions updated by release scripts.
Testing
55 tests covering:
Breaking changes
None. CLI interface and programmatic API remain identical. Package publishes to same
@fresh/initscope at JSR.Documentation