@xh/hoist 76.0.0-SNAPSHOT.1755394070476 → 76.0.0-SNAPSHOT.1755397026376

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.
@@ -14,24 +14,24 @@ so those projects can continue to stay on the most recent versions of Hoist.
14
14
 
15
15
  ## Essential Updates
16
16
 
17
- - Update to the latest `hoist-react` and `hoist-dev-utils` versions within your
18
- app's `package.json`.
19
- - Add `typescript` as a devDependency.
20
- - Use the major/minor version specified
21
- by [Hoist's own dependencies](https://github.com/xh/hoist-react/blob/develop/package.json).
22
- - We recommend using the `~` semver qualifier to allow auto-updates to newer patch releases
23
- only, e.g. `~4.9.5`.
24
- - Add a `tsconfig.json` file to your project's `/client-app` directory, right alongside your
25
- existing `package.json`.
26
- - Consult
27
- the [file included by Toolbox](https://github.com/xh/toolbox/blob/develop/client-app/tsconfig.json).
28
- - The settings will likely be the same as those required by your project, with the one exception
29
- of the `paths` entry in the Toolbox file. That supports developing hoist-react itself,
30
- alongside
31
- the application, and should be omitted from standard application projects.
32
- - Review and update to the "Breaking Changes" listed within
33
- Hoist's [CHANGELOG](https://github.com/xh/hoist-react/blob/develop/CHANGELOG.md) for the Hoist TS
34
- release and any other Hoist releases you are taking into your application with this update.
17
+ - Update to the latest `hoist-react` and `hoist-dev-utils` versions within your
18
+ app's `package.json`.
19
+ - Add `typescript` as a devDependency.
20
+ - Use the major/minor version specified
21
+ by [Hoist's own dependencies](https://github.com/xh/hoist-react/blob/develop/package.json).
22
+ - We recommend using the `~` semver qualifier to allow auto-updates to newer patch releases
23
+ only, e.g. `~4.9.5`.
24
+ - Add a `tsconfig.json` file to your project's `/client-app` directory, right alongside your
25
+ existing `package.json`.
26
+ - Consult
27
+ the [file included by Toolbox](https://github.com/xh/toolbox/blob/develop/client-app/tsconfig.json).
28
+ - The settings will likely be the same as those required by your project, with the one exception
29
+ of the `paths` entry in the Toolbox file. That supports developing hoist-react itself,
30
+ alongside
31
+ the application, and should be omitted from standard application projects.
32
+ - Review and update to the "Breaking Changes" listed within
33
+ Hoist's [CHANGELOG](https://github.com/xh/hoist-react/blob/develop/CHANGELOG.md) for the Hoist TS
34
+ release and any other Hoist releases you are taking into your application with this update.
35
35
 
36
36
  This should be a good checkpoint at which to run your application. Even without converting any app
37
37
  files to TS, you should be able to successfully compile and run - after adjusting for any of the
@@ -46,27 +46,27 @@ browsing through your application with the developer console open.
46
46
 
47
47
  The following deprecations will be common, but should be easy to adjust for:
48
48
 
49
- - Use of `modelConfig` vs. `model` when passing a model configuration as a component prop in the
50
- form of a plain-object. A case-sensitive search for `model: {` within your client source should
51
- provide a good starting point. Common with `Panel` models, as those are often specified inline.
52
- - Columns will now warn if they are passed unknown configuration keys - previously this was allowed,
53
- with any extra keys spread onto the Column instance as a way for apps to carry around some extra
54
- data. Use the new dedicated `Column.appData` config instead.
49
+ - Use of `modelConfig` vs. `model` when passing a model configuration as a component prop in the
50
+ form of a plain-object. A case-sensitive search for `model: {` within your client source should
51
+ provide a good starting point. Common with `Panel` models, as those are often specified inline.
52
+ - Columns will now warn if they are passed unknown configuration keys - previously this was allowed,
53
+ with any extra keys spread onto the Column instance as a way for apps to carry around some extra
54
+ data. Use the new dedicated `Column.appData` config instead.
55
55
 
56
56
  ## IDE / Tooling
57
57
 
58
58
  If using IntelliJ, ensure that your settings are configured correctly to get the most of out TS:
59
59
 
60
- - Under "Languages & Frameworks > JavaScript", ensure that your ESLint and (if enabled) Prettier
61
- configs include the `.ts` file extension.
62
- - Under "Languages & Frameworks > TypeScript", ensure that the IDE has picked up the TS distribution
63
- from your app's `node_modules` and that the TypeScript language service is enabled.
64
- - We recommend checking "show project errors" while leaving "recompile on changes" unchecked.
65
- - IntelliJ maintains distinct code style settings for JS vs. TS. You will likely want to review your
66
- TS code style settings and get in sync.
67
- - Consider
68
- copying [the Hoist project's `.editorconfig` file](https://github.com/xh/hoist-react/blob/develop/.editorconfig)
69
- into your project to apply XH-standardized settings automatically.
60
+ - Under "Languages & Frameworks > JavaScript", ensure that your ESLint and (if enabled) Prettier
61
+ configs include the `.ts` file extension.
62
+ - Under "Languages & Frameworks > TypeScript", ensure that the IDE has picked up the TS distribution
63
+ from your app's `node_modules` and that the TypeScript language service is enabled.
64
+ - We recommend checking "show project errors" while leaving "recompile on changes" unchecked.
65
+ - IntelliJ maintains distinct code style settings for JS vs. TS. You will likely want to review your
66
+ TS code style settings and get in sync.
67
+ - Consider
68
+ copying [Hoist React's .editorconfig](https://github.com/xh/hoist-react/blob/develop/.editorconfig)
69
+ into your project to apply XH-standardized settings automatically.
70
70
 
71
71
  If using Husky in your project for git hooks, consider adding `yarn run tsc` to your `pre-commit`
72
72
  check. Note that for `tsc` to run successfully, you will need to have _at least one_ TypeScript file
@@ -82,12 +82,12 @@ balancing the update with application/project priorities.
82
82
 
83
83
  This process boils down to:
84
84
 
85
- - Selecting a file or package to migrate.
86
- - Renaming all files within from `.js -> .ts` (and `.jsx -> .tsx` if you are using JSX).
87
- - Be sure to also rename any `index.js` files you might be using for imports within a given package.
88
- - Fixing any immediate TS compilation errors in the newly renamed files. The IDE or Webpack build
89
- should flag them, and you can also run `yarn tsc` to compile directly and review any warnings.
90
- - Begin strategically adding types within each file, focusing on public properties and APIs.
85
+ - Selecting a file or package to migrate.
86
+ - Renaming all files within from `.js -> .ts` (and `.jsx -> .tsx` if you are using JSX).
87
+ - Be sure to also rename any `index.js` files you might be using for imports within a given package.
88
+ - Fixing any immediate TS compilation errors in the newly renamed files. The IDE or Webpack build
89
+ should flag them, and you can also run `yarn tsc` to compile directly and review any warnings.
90
+ - Begin strategically adding types within each file, focusing on public properties and APIs.
91
91
 
92
92
  ### Bootstrap.ts + Service Declarations
93
93
 
@@ -98,9 +98,7 @@ rename with a `.ts` extension to ensure you have at least one TS file in your bu
98
98
  In that same file, add a declaration statement to let TS know about any of your application
99
99
  services (`HoistService` instances) that you are initializing. Those are installed on and referenced
100
100
  from the `XH` object; for TS to consider references to those services valid, it needs to know that
101
- the type of the `XH` singleton (`XHApi`) has a property for each of your services. For users of
102
- IntelliJ, an ignored re-declaration of the XH singleton with this interface helps the IDE properly
103
- notice uses of these services.
101
+ the type of the `XH` singleton (`XHApi`) has a property for each of your services.
104
102
 
105
103
  In Toolbox, we have the following within `Bootstrap.ts` to declare five TB-specific services (your
106
104
  services will vary of course) and a custom property installed on `HoistUser`, the type returned
@@ -116,8 +114,6 @@ declare module '@xh/hoist/core' {
116
114
  portfolioService: PortfolioService;
117
115
  taskService: TaskService;
118
116
  }
119
- // @ts-ignore - Help IntelliJ recognize uses of injected service methods from the `XH` singleton.
120
- export const XH: XHApi;
121
117
 
122
118
  export interface HoistUser {
123
119
  profilePicUrl: string;
@@ -149,15 +145,16 @@ The pace and completeness with which you migrate the rest of your app's codebase
149
145
  Consider prioritizing packages in an order similar to the below to get the most benefit early on
150
146
  from your TS upgrade:
151
147
 
152
- - _Services_ - often centralized business logic accessed from multiple parts of the app, a great
153
- candidate for typed functions and public properties.
154
- - _POJOs_ - if your app maintains any classes for data modeling, consider typing their public
155
- properties and any public instance methods.
156
- - _Utils_ - shared, app specific utility functions are good candidates for typing, with callers
157
- benefiting from typed parameters and return signatures.
158
- - _Models & Components_ - the bulk of your client-side codebase...
148
+ - _Services_ - often centralized business logic accessed from multiple parts of the app, a great
149
+ candidate for typed functions and public properties.
150
+ - _POJOs_ - if your app maintains any classes for data modeling, consider typing their public
151
+ properties and any public instance methods.
152
+ - _Utils_ - shared, app specific utility functions are good candidates for typing, with callers
153
+ benefiting from typed parameters and return signatures.
154
+ - _Models & Components_ - the bulk of your client-side codebase...
159
155
 
160
156
  ------------------------------------------
161
157
 
162
- 📫☎️🌎 info@xh.io | https://xh.io/contact
163
- Copyright © 2025 Extremely Heavy Industries Inc. - all rights reserved
158
+ ☎️ info@xh.io | <https://xh.io>
159
+
160
+ Copyright © 2025 Extremely Heavy Industries Inc.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@xh/hoist",
3
- "version": "76.0.0-SNAPSHOT.1755394070476",
3
+ "version": "76.0.0-SNAPSHOT.1755397026376",
4
4
  "description": "Hoist add-on for building and deploying React Applications.",
5
5
  "repository": "github:xh/hoist-react",
6
6
  "homepage": "https://xh.io",