@linebundle-sdk/ts 1.0.0-rc.1 → 1.0.0-rc.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,26 @@
1
+ # Contributing to This Repository
2
+
3
+ Thank you for your interest in contributing to this repository. Please note that this repository contains generated code. As such, we do not accept direct changes or pull requests. Instead, we encourage you to follow the guidelines below to report issues and suggest improvements.
4
+
5
+ ## How to Report Issues
6
+
7
+ If you encounter any bugs or have suggestions for improvements, please open an issue on GitHub. When reporting an issue, please provide as much detail as possible to help us reproduce the problem. This includes:
8
+
9
+ - A clear and descriptive title
10
+ - Steps to reproduce the issue
11
+ - Expected and actual behavior
12
+ - Any relevant logs, screenshots, or error messages
13
+ - Information about your environment (e.g., operating system, software versions)
14
+ - For example can be collected using the `npx envinfo` command from your terminal if you have Node.js installed
15
+
16
+ ## Issue Triage and Upstream Fixes
17
+
18
+ We will review and triage issues as quickly as possible. Our goal is to address bugs and incorporate improvements in the upstream source code. Fixes will be included in the next generation of the generated code.
19
+
20
+ ## Contact
21
+
22
+ If you have any questions or need further assistance, please feel free to reach out by opening an issue.
23
+
24
+ Thank you for your understanding and cooperation!
25
+
26
+ The Maintainers
package/FUNCTIONS.md ADDED
@@ -0,0 +1,89 @@
1
+ # Standalone Functions
2
+
3
+ > [!NOTE]
4
+ > This section is useful if you are using a bundler and targetting browsers and
5
+ > runtimes where the size of an application affects performance and load times.
6
+
7
+ Every method in this SDK is also available as a standalone function. This
8
+ alternative API is suitable when targetting the browser or serverless runtimes
9
+ and using a bundler to build your application since all unused functionality
10
+ will be tree-shaken away. This includes code for unused methods, Zod schemas,
11
+ encoding helpers and response handlers. The result is dramatically smaller
12
+ impact on the application's final bundle size which grows very slowly as you use
13
+ more and more functionality from this SDK.
14
+
15
+ Calling methods through the main SDK class remains a valid and generally more
16
+ more ergonomic option. Standalone functions represent an optimisation for a
17
+ specific category of applications.
18
+
19
+ ## Example
20
+
21
+ ```typescript
22
+ import { LineBundleCore } from "@linebundle-sdk/ts/core.js";
23
+ import { userGetAssistant } from "@linebundle-sdk/ts/funcs/userGetAssistant.js";
24
+
25
+ // Use `LineBundleCore` for best tree-shaking performance.
26
+ // You can create one instance of it to use across an application.
27
+ const lineBundle = new LineBundleCore({
28
+ security: {
29
+ oidc: "<YOUR_OIDC_HERE>",
30
+ },
31
+ });
32
+
33
+ async function run() {
34
+ const res = await userGetAssistant(lineBundle);
35
+ if (res.ok) {
36
+ const { value: result } = res;
37
+ console.log(result);
38
+ } else {
39
+ console.log("userGetAssistant failed:", res.error);
40
+ }
41
+ }
42
+
43
+ run();
44
+ ```
45
+
46
+ ## Result types
47
+
48
+ Standalone functions differ from SDK methods in that they return a
49
+ `Result<Value, Error>` type to capture _known errors_ and document them using
50
+ the type system. By avoiding throwing errors, application code maintains clear
51
+ control flow and error-handling become part of the regular flow of application
52
+ code.
53
+
54
+ > We use the term "known errors" because standalone functions, and JavaScript
55
+ > code in general, can still throw unexpected errors such as `TypeError`s,
56
+ > `RangeError`s and `DOMException`s. Exhaustively catching all errors may be
57
+ > something this SDK addresses in the future. Nevertheless, there is still a lot
58
+ > of benefit from capturing most errors and turning them into values.
59
+
60
+ The second reason for this style of programming is because these functions will
61
+ typically be used in front-end applications where exception throwing is
62
+ sometimes discouraged or considered unidiomatic. React and similar ecosystems
63
+ and libraries tend to promote this style of programming so that components
64
+ render useful content under all states (loading, success, error and so on).
65
+
66
+ The general pattern when calling standalone functions looks like this:
67
+
68
+ ```typescript
69
+ import { Core } from "<sdk-package-name>";
70
+ import { fetchSomething } from "<sdk-package-name>/funcs/fetchSomething.js";
71
+
72
+ const client = new Core();
73
+
74
+ async function run() {
75
+ const result = await fetchSomething(client, { id: "123" });
76
+ if (!result.ok) {
77
+ // You can throw the error or handle it. It's your choice now.
78
+ throw result.error;
79
+ }
80
+
81
+ console.log(result.value);
82
+ }
83
+
84
+ run();
85
+ ```
86
+
87
+ Notably, `result.error` above will have an explicit type compared to a try-catch
88
+ variation where the error in the catch block can only be of type `unknown` (or
89
+ `any` depending on your TypeScript settings).
package/README.md ADDED
@@ -0,0 +1,55 @@
1
+ # LineBundle TypeScript SDK
2
+
3
+ Type-safe TypeScript SDK for the [LineBundle API](https://docs.linebundle.com).
4
+
5
+ ## Installation
6
+
7
+ ```bash
8
+ npm install @linebundle-sdk/ts
9
+ ```
10
+
11
+ ## Quick Start
12
+
13
+ ```typescript
14
+ import { Linebundle } from '@linebundle-sdk/ts';
15
+
16
+ const sdk = new Linebundle({
17
+ auth: () => 'YOUR_API_KEY',
18
+ });
19
+
20
+ // List events
21
+ const events = await sdk.events.list();
22
+
23
+ // Create an event
24
+ const event = await sdk.events.create({
25
+ body: {
26
+ title: 'My Event',
27
+ start_dt: '2026-05-01',
28
+ start_tm: '10:00',
29
+ end_dt: '2026-05-01',
30
+ end_tm: '14:00',
31
+ timezone: 'Africa/Accra',
32
+ },
33
+ });
34
+ ```
35
+
36
+ ## Authentication
37
+
38
+ Pass a bearer token via the `auth` option. The function is called per-request, so it handles token refresh automatically:
39
+
40
+ ```typescript
41
+ const sdk = new Linebundle({
42
+ auth: async () => {
43
+ const token = await getTokenFromYourAuthProvider();
44
+ return token;
45
+ },
46
+ });
47
+ ```
48
+
49
+ ## SDK Reference
50
+
51
+ See the full [SDK Reference](https://docs.linebundle.com/sdk-reference/event) for all available methods.
52
+
53
+ ## License
54
+
55
+ MIT
package/RUNTIMES.md ADDED
@@ -0,0 +1,48 @@
1
+ # Supported JavaScript runtimes
2
+
3
+ This SDK is intended to be used in JavaScript runtimes that support ECMAScript 2020 or newer. The SDK uses the following features:
4
+
5
+ - [Web Fetch API][web-fetch]
6
+ - [Web Streams API][web-streams] and in particular `ReadableStream`
7
+ - [Async iterables][async-iter] using `Symbol.asyncIterator`
8
+
9
+ [web-fetch]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
10
+ [web-streams]: https://developer.mozilla.org/en-US/docs/Web/API/Streams_API
11
+ [async-iter]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols#the_async_iterator_and_async_iterable_protocols
12
+
13
+ Runtime environments that are explicitly supported are:
14
+
15
+ - Evergreen browsers which include: Chrome, Safari, Edge, Firefox
16
+ - Node.js active and maintenance LTS releases
17
+ - Currently, this is v18 and v20
18
+ - Bun v1 and above
19
+ - Deno v1.39
20
+ - Note that Deno does not currently have native support for streaming file uploads backed by the filesystem ([issue link][deno-file-streaming])
21
+
22
+ [deno-file-streaming]: https://github.com/denoland/deno/issues/11018
23
+
24
+ ## Recommended TypeScript compiler options
25
+
26
+ The following `tsconfig.json` options are recommended for projects using this
27
+ SDK in order to get static type support for features like async iterables,
28
+ streams and `fetch`-related APIs ([`for await...of`][for-await-of],
29
+ [`AbortSignal`][abort-signal], [`Request`][request], [`Response`][response] and
30
+ so on):
31
+
32
+ [for-await-of]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for-await...of
33
+ [abort-signal]: https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal
34
+ [request]: https://developer.mozilla.org/en-US/docs/Web/API/Request
35
+ [response]: https://developer.mozilla.org/en-US/docs/Web/API/Response
36
+
37
+ ```jsonc
38
+ {
39
+ "compilerOptions": {
40
+ "target": "es2020", // or higher
41
+ "lib": ["es2020", "dom", "dom.iterable"]
42
+ }
43
+ }
44
+ ```
45
+
46
+ While `target` can be set to older ECMAScript versions, it may result in extra,
47
+ unnecessary compatibility code being generated if you are not targeting old
48
+ runtimes.
package/USAGE.md ADDED
@@ -0,0 +1,20 @@
1
+ <!-- Start SDK Example Usage [usage] -->
2
+ ```typescript
3
+ import { LineBundle } from "@linebundle-sdk/ts";
4
+
5
+ const lineBundle = new LineBundle({
6
+ security: {
7
+ oidc: "<YOUR_OIDC_HERE>",
8
+ },
9
+ });
10
+
11
+ async function run() {
12
+ const result = await lineBundle.user.getAssistant();
13
+
14
+ console.log(result);
15
+ }
16
+
17
+ run();
18
+
19
+ ```
20
+ <!-- End SDK Example Usage [usage] -->
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@linebundle-sdk/ts",
3
- "version": "1.0.0-rc.1",
3
+ "version": "1.0.0-rc.2",
4
4
  "author": "LineBundle",
5
5
  "type": "module",
6
6
  "main": "./esm/index.js",