🚀 Big News: Socket Acquires Coana to Bring Reachability Analysis to Every Appsec Team.Learn more
Socket
Book a DemoInstallSign in
Socket

@telus/create-library

Package Overview
Dependencies
Maintainers
18
Versions
68
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@telus/create-library - npm Package Compare versions

Comparing version

to
1.16.0

29

package.json
{
"version": "1.15.2",
"version": "1.16.0",
"name": "@telus/create-library",

@@ -35,6 +35,5 @@ "description": "an opinionated npm package initializer",

"scripts": {
"lint:audit": "npx audit-ci@6.3.0 --config .audit-ci.jsonc",
"lint:audit": "npx audit-ci --config .audit-ci.jsonc",
"lint:ec": "editorconfig-checker",
"lint:js": "npx @telus/telus-standard --verbose",
"lint:md": "npx remark-cli --quiet --frail .",
"lint": "npm-run-all -p -c -l lint:*",

@@ -48,16 +47,18 @@ "fix:js": "npm run lint:js -- --fix",

"fast-glob": "^3.2.12",
"inquirer": "^8.2.3",
"mkdirp": "^1.0.4",
"inquirer": "^9.2.6",
"mkdirp": "^3.0.1",
"spdx-license-list": "^6.6.0",
"validate-npm-package-name": "^3.0.0",
"yargs": "^17.6.2"
"validate-npm-package-name": "^5.0.0",
"yargs": "^17.7.2"
},
"devDependencies": {
"@commitlint/cli": "^17.3.0",
"@commitlint/config-angular": "^17.3.0",
"@telus/prettier-config": "^3.2.4",
"@telus/remark-config": "^2.2.5",
"@telus/semantic-release-config": "^2.2.5",
"editorconfig-checker": "^4.0.2",
"husky": "^4.3.8",
"@commitlint/cli": "^17.6.3",
"@commitlint/config-conventional": "^17.6.3",
"@telus/prettier-config": "^3.3.0",
"@telus/remark-config": "^2.3.0",
"@telus/semantic-release-config": "^2.4.0",
"@telus/telus-standard": "^4.1.0",
"audit-ci": "^6.6.1",
"editorconfig-checker": "^5.0.1",
"husky": "^8.0.3",
"npm-run-all": "^4.1.5"

@@ -64,0 +65,0 @@ },

@@ -0,7 +1,9 @@

![maintenance-status](https://img.shields.io/badge/maintenance-passively--maintained-yellowgreen.svg)
![npm (scoped)](https://img.shields.io/npm/v/@telus/create-library)
# NPM Library Initializer
[![version][npm-image]][npm-url]
An opinionated [npm package initializer](https://docs.npmjs.com/cli/init#description). Scaffolds an npm library tree with fully configured CI automation, using a predefined [template](./template).
An opinionated [npm package initializer][npm-init]. Scaffolds an npm library tree with fully configured CI automation, using a predefined [template](./template).
Use this to easily scaffold an NPM package for use within TELUS.

@@ -22,9 +24,9 @@

- We use Git _feature branches_, which allow us to isolate the development work and instantly get feedback as to how the changes impact the the unit tests and lint checks (using Github actions and integrated status checks).
- We believe in _the power of automation_, which is why we have opted for automated semantic versioning and releasing using [semantic-release][semantic-release]. The template pipeline is configured to only run the `release` step on the `master` branch, which is why it is vital that only good code gets pushed to it.
- We use Git _feature branches_, which allow us to isolate the development work and instantly get feedback as to how the changes impact the unit tests and lint checks (using Github actions and integrated status checks).
- We believe in _the power of automation_, which is why we have opted for automated semantic versioning and releasing using [semantic-release](https://github.com/semantic-release/semantic-release). The template pipeline is configured to only run the `release` step on the `master` branch, which is why it is vital that only good code gets pushed to it.
- Given this, we encourage implementing _branch protection for the `master` branch_ and merging changes into it following a pull request process, with at least one approval required. Having the unit tests and lint checks run in the CI pipeline automatically allows the PR reviewers to focus on the actual code changes, without having to always pull the respective branch locally to confirm no issues are introduced.
- Automation of the package release workflow is made possible by following _formalized git commit conventions_, more specifically [angular-commit-conventions][angular-commit-conventions]. This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specs. Please refer to our [semantic-release][guides-semantic-release] guide for more details about how this works.
- We are fans of _configuration as code_, which is why we are taking advantage of Github's [Probot][probot-settings] framework to store the repository settings as [code](./.github/settings.yml). Please review these and configure as needed. We encourage the practice of squashing commits and keeping a clean commit history (without standard merge commits cluttering the history). If squashing commits is a practice your team chooses to use, you will have the responsibility to ensure that the squashed commit message follows the Angular commit conventions and captures all included changes correctly.
- We believe there is a lot of value in having _consistent code style_ across all of our projects, which is why we have centralized the configuration of our code quality and style checking tools in external libraries, such as [@telus/telus-standard][telus/telus-standard], [@telus/remark-config][telus/remark-config], etc. We encourage teams to use our centralized config packages and not override particular rules; our configuration is open to suggestions to contributions (feel free to add issues and/or open PRs in the repositories of the above mentioned packages).
- We believe in automation and in _leveraging automated code formatters_ such as [prettier][prettier]. The scaffolded library will be configured out of the box to automatically format all the staged files when the user commits. For that, we are using [husky][husky] to configure the pre-commit hook and restrict the formatting to the staged files that are part of the commit.
- Automation of the package release workflow is made possible by following _formalized git commit conventions_, more specifically [conventional-commit-conventions](https://www.conventionalcommits.org/en/v1.0.0/). This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specs. Please refer to our [semantic-release][guides-semantic-release] guide for more details about how this works.
- We are fans of _configuration as code_, which is why we are taking advantage of Github's [Probot](https://github.com/probot/settings) framework to store the repository settings as [code](./.github/settings.yml). Please review these and configure as needed. We encourage the practice of squashing commits and keeping a clean commit history (without standard merge commits cluttering the history). If squashing commits is a practice your team chooses to use, you will have the responsibility to ensure that the squashed commit message follows the Angular commit conventions and captures all included changes correctly.
- We believe there is a lot of value in having _consistent code style_ across all of our projects, which is why we have centralized the configuration of our code quality and style checking tools in external libraries, such as [@telus/telus-standard](https://github.com/telus/telus-standard), [@telus/remark-config](https://github.com/telus/remark-config), etc. We encourage teams to use our centralized config packages and not override particular rules; our configuration is open to suggestions to contributions (feel free to add issues and/or open PRs in the repositories of the above mentioned packages).
- We believe in automation and in _leveraging automated code formatters_ such as [prettier](https://prettier.io/). The scaffolded library will be configured out of the box to automatically format all the staged files when the user commits. For that, we are using [husky](https://github.com/typicode/husky) to configure the pre-commit hook and restrict the formatting to the staged files that are part of the commit.

@@ -41,16 +43,15 @@ ## <a id="step-1"></a> Requirements

- Scaffolded NPM library, with automatically generated `package.json` and Github settings based on user input
- Github Actions for a standard workflow, including installing dependencies, testing, linting, and automated releases
- Automated version management and NPM package publishing using [semantic-release](https://github.com/semantic-release/semantic-release), that uses formalized commit message convention to document changes in the codebase
- Basic setup for unit tests with [tap](https://github.com/tapjs/node-tap)
- Security auditing using [npm audit](https://docs.npmjs.com/cli/audit)
- `.editorconfig` linting using [editorconfig-checker](https://github.com/editorconfig-checker/editorconfig-checker.javascript)
- Javascript linting using [telus-standard](https://github.com/telus/telus-standard), and a command to automatically fix most small issues
- Automated dependency updates using Dependabot
- Github repository settings as code living in the repository of your library (see [probot/settings][probot-settings] for more details)
- Github Actions [configuration file](./template/.github/main.workflow) for a standard workflow, including installing dependencies, testing, linting, and automated releases
- Automated version management and NPM package publishing using [semantic-release][semantic-release], that uses formalized commit message convention to document changes in the codebase
- Basic setup for unit tests with [tap][tap]
- Security auditing using [npm audit][npm-audit]
- `.editorconfig` linting using [editorconfig-checker][editorconfig]
- Javascript linting using [telus-standard][telus-standard], and a command to automatically fix most small issues
- Markdown linting for your README files using [remark-cli][remark-cli], and a command to automatically fix most small issues
- Automated dependency updates using [renovate bot][renovate]
Some of the tools mentioned above rely on centralized configuration files, that allow us to achieve consistency across all of the applications built by our team, and remove duplicated configs across all of our repositories. You are welcome to open a PR in either of these if you would like to suggest any changes:
- `telus-standard` (Javascript linting with our own flavour of StandardJS) - see [@telus/telus-standard][telus/telus-standard]
- `remark` (Markdown linting) - see [@telus/remark-config][telus/remark-config]
- `telus-standard` (Javascript linting with our own flavour of StandardJS) - see [@telus/telus-standard](https://github.com/telus/telus-standard)
- `remark` (Markdown linting) - see [@telus/remark-config](https://github.com/telus/remark-config)

@@ -82,3 +83,3 @@ ## <a id="step-3"></a> Usage

- repository name
- license type (read more about license types [here][github-licenses])
- license type (read more about [license types](https://help.github.com/articles/licensing-a-repository/))
- keywords

@@ -89,3 +90,3 @@ - maintainers (Github team slug)

The `npm init` command was solely used to create a new `package.json` file. As of npm v6.1.0, `npm init` can be used as an initializer by passing the name of the package you want initialized after `npm init`; npm will prepend `create-` to the name of the initializer you provide and use `npx` to temporarily install and execute that project. You can read more about this [here][npm-init].
The `npm init` command was solely used to create a new `package.json` file. As of npm v6.1.0, `npm init` can be used as an initializer by passing the name of the package you want initialized after `npm init`; npm will prepend `create-` to the name of the initializer you provide and use `npx` to temporarily install and execute that project. You can read more about this [here](https://docs.npmjs.com/cli/init#description).

@@ -111,3 +112,3 @@ As a result, this is what happens after you run `npm init @telus/library`:

- Pay special attention to `package.json` and your `README` files, as these will be completely replaced; however, you'll want to merge what you had in there before with what gets generated.
- If you run into any issues, reach out to the [Architecture Support Team][ast-confluence].
- If you run into any issues, reach out to the [Architecture Support Team](https://telusdigital.atlassian.net/wiki/spaces/AST/overview).

@@ -122,3 +123,3 @@ ### 2. How do I keep up with the updates?

- Review the `package.json` `files` section and specify what files you would like included when your package is installed as a dependency. You can publish both your `src` and `lib` (or `dist`) if you would like your package consumers to be able to access the source code, or you can opt to only publish the distribution files (transpiled code). See more details about how this works [here][npm-files]. Feel free to add an `.npmignore` file if needed.
- Review the `package.json` `files` section and specify what files you would like included when your package is installed as a dependency. You can publish both your `src` and `lib` (or `dist`) if you would like your package consumers to be able to access the source code, or you can opt to [only publish the distribution files](https://docs.npmjs.com/files/package.json#files) (transpiled code). Feel free to add an `.npmignore` file if needed.
- Consider adding a `prepare` or `prepublishOnly` script to automate building & updating the distribution files. You can read more about these if you run `npm help scripts`.

@@ -143,4 +144,4 @@ - Consider adding your `lib`/`dist` folder to the `.gitignore`, especially if you automate the creation of these assets. It makes sense for only source files to be committed in the repository, especially as transpiled code is often hard to read (there have been incidents where malicious code has been included on purpose within the transpiled code and made it into published packages).

- [Github Actions][github-actions]
- [semantic-release][guides-semantic-release]
- [GitHub Actions](https://developer.github.com/actions/)
- [Semantic Release](https://github.com/telus/guides/blob/master/semantic-release.md)

@@ -151,24 +152,1 @@ ---

> Twitter: [@telusdigital](https://twitter.com/telusdigital)
[npm-url]: https://www.npmjs.com/package/@telus/create-library
[npm-image]: https://img.shields.io/npm/v/@telus/create-library.svg?style=for-the-badge&logo=npm
[npm-library-starter-kit]: https://github.com/telus/npm-library-starter-kit
[angular-commit-conventions]: https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines
[probot-settings]: https://github.com/probot/settings
[semantic-release]: https://github.com/semantic-release/semantic-release
[tap]: https://github.com/tapjs/node-tap
[npm-audit]: https://docs.npmjs.com/cli/audit
[editorconfig]: https://github.com/editorconfig-checker/editorconfig-checker.javascript
[telus-standard]: https://github.com/telus/telus-standard
[remark-cli]: https://github.com/remarkjs/remark/tree/master/packages/remark-cli
[renovate]: https://github.com/renovatebot/renovate
[telus/telus-standard]: https://github.com/telus/telus-standard
[telus/remark-config]: https://github.com/telus/remark-config
[prettier]: https://prettier.io/
[husky]: https://github.com/typicode/husky
[github-licenses]: https://help.github.com/articles/licensing-a-repository/
[npm-init]: https://docs.npmjs.com/cli/init#description
[ast-confluence]: https://telusdigital.atlassian.net/wiki/spaces/AST/overview
[npm-files]: https://docs.npmjs.com/files/package.json#files
[guides-semantic-release]: https://github.com/telus/guides/blob/master/semantic-release.md
[github-actions]: https://developer.github.com/actions/