JSDA-Kit 1.6.x -- What's New?
JSDA-Kit's static pipeline has grown from "turn ESM files into web assets" into a more complete publishing workflow. The latest additions focus on the cases that usually force small sites and documentation projects to bolt on extra scripts: rendering PDFs, discovering non-index entry files, copying prebuilt assets, and making Markdown links safer by default.
Together, these features keep the JSDA model intact. Pages, feeds, reports, and supporting files still live close to the source code that creates them, but the build step now has more precise rules for what to render and what to pass through untouched.
PDF Rendering from JSDA Entries
JSDA-Kit can now render .pdf.js entries through Puppeteer with the dedicated PDF build commands:
npx jsda build-pdf
npx jsda ssg-pdf
Regular build and ssg runs skip PDF entries so day-to-day development stays fast. When a project needs printable reports, invoices, documentation exports, or archived snapshots, PDF generation can be enabled only for the builds that need it.
A PDF entry uses the same default-export pattern as any other JSDA static asset:
// src/static/reports/annual.pdf.js
export const pdfOptions = {
format: 'A4',
printBackground: true,
margin: {
top: '16mm',
right: '16mm',
bottom: '16mm',
left: '16mm',
},
};
export default `
<!doctype html>
<html>
<body>
<h1>Annual Report</h1>
</body>
</html>
`;
Project-wide PDF defaults live under static.pdf, including Puppeteer launch options, render timing, output location, and page.pdf() options:
export default {
static: {
pdf: {
waitUntil: 'load',
outputDir: '',
launchOptions: {},
options: {
format: 'A4',
printBackground: true,
},
},
},
};
If static.pdf.outputDir is set, generated PDFs can be written somewhere other than the main static output directory. One useful pattern is generating PDFs into a committed copy-pdf folder, then letting CI copy those files into dist without needing Puppeteer in every deployment environment.
Configurable Entry Patterns
The static builder no longer has to be limited to index.js and index.*.js files. static.entryPatterns lets a project opt into additional JSDA entry names while keeping the default convention small and predictable.
export default {
static: {
entryPatterns: [
'index.js',
'index.*.js',
'llms.txt.js',
'robots.txt.js',
'*.html.js',
'*.xml.js',
'*.pdf.js',
],
},
};
With those patterns enabled, files such as these become first-class generated outputs:
src/static/about.html.js -> dist/about.html
src/static/feed.xml.js -> dist/feed.xml
src/static/report.pdf.js -> dist/report.pdf
Filename-only patterns, such as *.html.js, match files at any depth under static.sourceDir. Relative path patterns, such as pages/*.html.js, can be used when a project wants more targeted discovery.
This gives teams a cleaner choice: keep the original index-based structure for route-like assets, or use named files when the output itself is the important object, such as feeds, metadata documents, standalone pages, or reports.
Static Copy Settings
Some assets should not be rendered, bundled, minified, or interpreted at all. JSDA-Kit now supports explicit copy rules through static.copy:
export default {
static: {
copy: [
{ from: './generated/pdf', to: './pdf' },
{ from: './public', to: './' },
],
},
};
Copy rules can point at files or directories. The to path is relative to static.outputDir, which makes the final destination easy to reason about during builds.
For colocated assets, JSDA-Kit also supports zero-config copy folders. Any folder under static.sourceDir whose name starts with copy- is copied as raw files, and the prefix is stripped in the output:
src/static/copy-assets/favicon.ico -> dist/assets/favicon.ico
src/static/reports/copy-pdf/annual-report.pdf -> dist/reports/pdf/annual-report.pdf
Files inside copy-* folders are never processed as JSDA entries. That means a file named index.html.js inside copy-assets is copied as index.html.js, not rendered into index.html.
The build also checks for output conflicts. If a copied file would overwrite a generated file, the build fails instead of silently replacing one asset with another.
Automatic Targets for External Markdown Links
The Markdown renderer now handles external links with safer defaults. Links [Link](...) which starts with http://, https://, or // receive configured target and rel attributes automatically in HTML-output:
<a target="_blank" rel="noopener noreferrer" href="https://example.com">
Example
</a>
The defaults are configured under markdown.externalLinks:
export default {
markdown: {
externalLinks: {
enabled: true,
target: '_blank',
rel: 'noopener noreferrer',
exclude: [],
},
},
};
Internal links, hash links, relative links, mailto: links, and tel: links are left alone. If a project needs exceptions for trusted domains or special link behavior, exclude can skip URLs containing specific substrings. The feature can also be disabled entirely with enabled: false.
This keeps authored Markdown simple while making rendered documentation and content pages behave consistently across the site.
A More Complete Publishing Pipeline
These features are small individually, but they solve a shared problem: real static sites usually have more than HTML pages. They have feeds, PDFs, copied downloads, favicons, generated reports, Markdown content, and CI constraints.
JSDA-Kit now covers more of that workflow without changing its core idea. Source files remain ordinary ESM modules. Configuration stays in one project.cfg.js. The output is still plain deployable files. The difference is that the build can now render, skip, copy, and annotate assets with enough nuance for production publishing.