nw-style-guide 14.1.0 → 14.2.0
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.
- package/README.md +32 -7
- package/package.json +1 -1
- package/tooltips/tooltip.directive.d.ts +1 -1
package/README.md
CHANGED
|
@@ -68,6 +68,38 @@ $nw-font-path: '~nw-style-guide/assets/fonts';
|
|
|
68
68
|
/npm.fontawesome.com/:_authToken=xxxxxxxxxxxxxxxxxxxxxxx // replace with Fontawesome Pro authToken
|
|
69
69
|
//registry.npmjs.org/:_authToken=xxxxxxxxxxxxxxxxxxxxxxx // replace with your authToken from npm
|
|
70
70
|
```
|
|
71
|
+
|
|
72
|
+
|
|
73
|
+
### Building local versions
|
|
74
|
+
|
|
75
|
+
Sometimes when making extensive changes that require continuous local testing inside the product we need to create local versions. For this purpose we can run the `make-local-tgz` script and use it as follows:
|
|
76
|
+
- Make a `.tgz` package of Style Guide by running `npm run package:make-local-tgz`.
|
|
77
|
+
- Copy absolute path of newly built `.tgz` package from console logs.
|
|
78
|
+
- Paste it into the product's (e.g. Spike's) `package.json` file in place of the current `nw-style-guide` version to test your SG changes locally, without the need to publish a beta version.
|
|
79
|
+
- Run `npm install` to install the new package version.
|
|
80
|
+
- Sometimes if you dont see your changes, delete the `node_modules` folder from your Project (e.g. Spike) and run `npm install again`.
|
|
81
|
+
- If you want to confirm whether or not the new style guide version has been installed, navigate to your `node_modules` folder and look for the style guide directory and inside the `package.json` file you can confirm the version number.
|
|
82
|
+
|
|
83
|
+
### Building a Beta version for testing
|
|
84
|
+
|
|
85
|
+
Most of the time we would need to deploy our application (e.g. Spike) to a test env to allow others to test and to make sure the changes we have added to the style guide project are functioning and or looking as expected.
|
|
86
|
+
|
|
87
|
+
To do so we usually create a Beta version which we release to npm.
|
|
88
|
+
|
|
89
|
+
To achieve this we need to:
|
|
90
|
+
- Update the version of the style guide version property in `package.json` to a beta version using `npm version {{version_type}}` for example "npm version 14.0.1-beta.0"
|
|
91
|
+
- Once updated we're now ready to push the new version to npm using this command `npm run package:release`
|
|
92
|
+
- Once that version is pushed check the npm website where the package is deployed to confirm the latest version deployed is the one you just added https://www.npmjs.com/package/nw-style-guide.
|
|
93
|
+
- In your Spike or other project change the `nw-style-guide` version in `package.json` to this new version and push and deploy the changes to a test env.
|
|
94
|
+
- Once changes are approved and everything is looking fine we then need to update the `nw-style-guide` version to remove the beta.0. to do that we call the same command we called earlier `npm version {{version_type}}` it can also be done manually but this command is better as it auto commits the changes.
|
|
95
|
+
(just a note from my experience you don't need to include the beta.0 but I'm guessing i'ts good here because if we want to deploy another beta version we would only need to incremenet that 0 to 1 and so on).
|
|
96
|
+
- Then we push the latest changes to Github.
|
|
97
|
+
- Once approved, merge the changes into master and a new version will be released shortly automatically. You'll most likely recieve a notification via email and or slack of this new version.
|
|
98
|
+
- Go back to your project (e.g. Spike) and update the nw-style-guide version in the `package.json` to use the new version you just committed.
|
|
99
|
+
- push changes and merge, assuming it has been approved.
|
|
100
|
+
- Thats it you're done.
|
|
101
|
+
|
|
102
|
+
|
|
71
103
|
### Features and fixes
|
|
72
104
|
|
|
73
105
|
1. Create a new feature branch off master
|
|
@@ -125,10 +157,3 @@ This script does a few things:
|
|
|
125
157
|
### Github pages
|
|
126
158
|
|
|
127
159
|
We use Github pages to continuously deploy the application. This deployment is handled automatically with the [build-and-deploy-docs](./.github/workflows/build-and-deploy-docs.yml) Github workflow. Whenever the master branch is updated, you can expect this workflow to trigger.
|
|
128
|
-
|
|
129
|
-
### Building local versions
|
|
130
|
-
|
|
131
|
-
Sometimes we won't want to release a beta version for testing changes, namely when making extensive changes that require continuous local testing inside the product. For this purpose we can run the `make-local-tgz` script and use it as follows:
|
|
132
|
-
- Make a `.tgz` package of Style Guide by running `npm run package:make-local-tgz`.
|
|
133
|
-
- Copy absolute path of newly built `.tgz` package from console logs.
|
|
134
|
-
- Paste it into the product's (e.g. Spike's) `package.json` file in place of the current `nw-style-guide` version to test your SG changes locally, without the need to publish a beta version.
|
package/package.json
CHANGED
|
@@ -71,7 +71,7 @@ export declare class TooltipDirective implements OnInit, OnChanges, OnDestroy {
|
|
|
71
71
|
/**
|
|
72
72
|
* In the case where the tooltip should not be attached to the host element, a reference to another element can be used
|
|
73
73
|
*/
|
|
74
|
-
connectedTo: ElementRef<HTMLElement
|
|
74
|
+
connectedTo: ElementRef<HTMLElement> | Element;
|
|
75
75
|
/**
|
|
76
76
|
* Determines whether pointer events are enabled on the cdk-overlay-pane element
|
|
77
77
|
*/
|