Skip to content

Commit 89b65c0

Browse files
authored
Merge pull request #778 from smapiot/develop
Release 1.9.0
2 parents b100b98 + 9928f60 commit 89b65c0

File tree

74 files changed

+1156
-972
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

74 files changed

+1156
-972
lines changed

.github/workflows/size.yml

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,7 @@ jobs:
1616
with:
1717
node-version: "20.12.2"
1818
- run: yarn install
19+
- run: yarn install --ignore-scripts
1920
- name: Report changes
2021
run: node ./tools/size-reporter.mjs
2122
env:

CHANGELOG.md

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,23 @@
11
# Piral Changelog
22

3+
## 1.9.0 (tbd)
4+
5+
- Fixed platform providers for `piral-ng` with Angular 20 in non-standalone form (#764)
6+
- Fixed debug mode deserialization in case of modifications from other security contexts (#775)
7+
- Removed `container` property from the `unhandled-error` event arguments (#777)
8+
- Improved dialog order in `piral-modals` (#773) by @pranav-hsg
9+
- Improved output when installation of packages fails (#759)
10+
- Improved error message when template resolution fails (#763)
11+
- Updated some dependencies such as `axios` (#765)
12+
- Updated `dets` to latest release
13+
- Updated `piral-cli-webpack5` to never output empty `main.css` files in pilets
14+
- Updated `piral-oidc` to use up-to-date `oidc-client-ts` instead of discontinued `oidc-client` library (#769)
15+
- Added support for Angular 20 in `piral-ng`
16+
- Added warning in `piral-cli` when shared dependencies are wrongly declared (#768)
17+
- Added support for Promise-based Webpack configuration files in `piral-cli-webpack5` (#774) by @grant-progress
18+
- Added `remoteTypesSource` to *piral.json* for specifying an URL for extra declarations
19+
- Added `remoteTypesTarget` to *pilet.json* for storing obtained extra declarations locally
20+
321
## 1.8.5 (April 15, 2025)
422

523
- Fixed generation of declarations during `pilet build` in the `piral-cli`

docs/concepts/T03-templates.md

Lines changed: 48 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,7 @@ Registry selection:
3333

3434
A custom template is just an npm package that fulfills the following requirements:
3535

36-
1. Expose a CommonJS module (`main` in the *package.json*)
36+
1. Expose a **CommonJS module** (`main` in the *package.json*)
3737
2. Have a `default` export being a function specified below
3838
3. Have `template` and either `pilet` (for pilets) or `piral` (for Piral instances) as keyword
3939

@@ -84,3 +84,50 @@ interface ExecutionDetails {
8484
```
8585

8686
This way, the template packages are essentially factories to create virtual files which are then written out by the `piral-cli`.
87+
88+
The easiest way to have a convenient codebase and adhere to the CommonJS output is to use a bundler such as `esbuild`. For instance, the following code (stored in *src/index.js*) would not work directly:
89+
90+
```js
91+
import { createPiletTemplateFactory } from '@smapiot/template-utils';
92+
93+
const root = resolve(__dirname, '..');
94+
95+
export default createPiletTemplateFactory(root, () => [
96+
{
97+
languages: ['js', 'ts'],
98+
name: 'foo.txt',
99+
target: '<src>/foo.txt',
100+
},
101+
]);
102+
```
103+
104+
Here, we use an ES module. To bring that conveniently and efficiently into a CommonJS module you can use the following *package.json*:
105+
106+
```json
107+
{
108+
"name": "@custom/template",
109+
"version": "1.0.0",
110+
"keywords": ["template", "pilet"],
111+
"engines": {
112+
"node": ">=16.0",
113+
"piral": "1.x"
114+
},
115+
"templateOptions": {},
116+
"author": "Your name",
117+
"license": "MIT",
118+
"main": "lib/index.js",
119+
"files": [
120+
"lib",
121+
"src",
122+
"templates"
123+
],
124+
"scripts": {
125+
"build": "esbuild src/index.js --bundle --outfile=./lib/index.js --platform=node"
126+
},
127+
"devDependencies": {
128+
"@smapiot/template-utils": "^1.0.13"
129+
}
130+
}
131+
```
132+
133+
Importantly, you can run `npm run build` to convert the original ES module codebase to a single file stored in *lib/index.js*. This way, you do not need to declare runtime dependencies such as `@smapiot/template-utils` (they can remain a development-only dependency) and you obtain a legit CommonJS module.

docs/static/schemas/pilet-v0.json

Lines changed: 14 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -28,6 +28,19 @@
2828
],
2929
"description": "The default behavior for implicitly defined versions of shared dependencies."
3030
},
31+
"remoteTypesTarget": {
32+
"description": "The absolute or relative location of the file that is written with the remote types, if any. Default is './src/remote.d.ts'.",
33+
"oneOf": [
34+
{
35+
"type": "boolean",
36+
"description": "A truthy value indicates that the default value should be used. Otherwise, nothing is written."
37+
},
38+
{
39+
"type": "string",
40+
"description": "The absolute or relative location of the file with the remote types."
41+
}
42+
]
43+
},
3144
"piralInstances": {
3245
"type": "object",
3346
"description": "The app shells to be used for debugging the pilet. Each key defines the name of a Piral instance to be selectable.",
@@ -58,4 +71,4 @@
5871
}
5972
}
6073
}
61-
}
74+
}

docs/static/schemas/piral-v0.json

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -92,6 +92,10 @@
9292
],
9393
"description": "Defines how the styles for the web components are transported. 'inline' puts them on the web components when rendering, 'sheet' includes a stylesheet when bundling, 'none' requires you to include them somewhere. By default, 'inline' is used."
9494
},
95+
"remoteTypesSource": {
96+
"type": "string",
97+
"description": "The URL of the generated d.ts combining extra type information from all pilets."
98+
},
9599
"shared": {
96100
"type": "array",
97101
"items": {

docs/tutorials/11-server-side-rendering.md

Lines changed: 0 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -168,53 +168,6 @@ The diagram below shows this sequence.
168168

169169
**Remark**: The replacement for the embedded data needs to be placed *before* the root module (in the example above `<script src="index.tsx"></script>`) is referenced.
170170

171-
The embedded data is either the data from the pilet feed (this section) or the data from the feed including the pilets (see next section).
172-
173-
## Embedding the Pilets
174-
175-
Embedding the pilet feed may already be enough to provide improved startup performance. Nevertheless, especially for "cold starts", i.e., where no pilets have yet been seen or loaded, it can make sense to also deliver the pilets with the initial response.
176-
177-
Following the approach described beforehand, we can extend the `sendIndex` function to also include the pilets.
178-
179-
The only thing to add is the `getPilet` function in the provided options. This way, we can tell the SSR utility how to retrieve a pilet from its link.
180-
181-
```ts
182-
import axios from 'axios';
183-
import { createApp } from '../common/app';
184-
185-
const feedUrl = 'https://feed.piral.cloud/api/v1/pilet/sample';
186-
187-
function readRemoteText(link: string) {
188-
return axios.get(link).then(res => res.data);
189-
}
190-
191-
async function readRemoteJson(link: string) {
192-
const content = await readRemoteText(link);
193-
return JSON.parse(content);
194-
}
195-
196-
async function sendIndex(_: express.Request, res: express.Response) {
197-
const app = createApp();
198-
const content = await renderFromServer(app, {
199-
getPilet(url) {
200-
return readRemoteText(url);
201-
},
202-
async getPiletsMetadata() {
203-
const res = await readRemoteJson(feedUrl);
204-
return res.items;
205-
},
206-
fillTemplate(body, script) {
207-
return indexHtml
208-
.replace('<div id="app"></div>', `<div id="app">${body}</div>`)
209-
.replace('<noscript id="data"></noscript>', script);
210-
},
211-
});
212-
res.send(content);
213-
}
214-
```
215-
216-
Generally, this approach gives us quite some flexibility. It allows us to use caching in addition to HTTP requests. It also allows us to embed a pilet feed directly on the server-side, potentially not requiring any feed seen outside.
217-
218171
## Conclusion
219172

220173
SSR can be helpful to improve startup performance and user experience. The cost of optimizing the backend is, however, not negligible and should be considered, too. Providing the fastest response possible to pilet feed and general page requests could be already sufficient to ensure a great user experience.

docs/tutorials/15-share-dependencies.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -140,7 +140,7 @@ The rule of thumb for sharing the type declarations is: Everything exported top-
140140

141141
### Exported Modules
142142

143-
To simplify the process illustrated in the previous two sections you can use a special key called `shared` in your *pilet.json*, e.g.:
143+
To simplify the process illustrated in the previous two sections you can use a special key called `shared` in your *piral.json*, e.g.:
144144

145145
```json
146146
{

0 commit comments

Comments
 (0)