Skip to content
/ visma Public

Tools, snippets, helpers and other utility packages by Frontend discipline and contributors.

Notifications You must be signed in to change notification settings

Visma-AS/visma

Repository files navigation

Visma

Tools, snippets, helpers and other utility packages by Frontend discipline and contributors.

Contributions are welcome!

vfd-v3-transparent

Packages

Plugins & Presets

Templates

Tools

Helpers & Utilities

Configs

How to add a new package?

  1. Clone this repository

  2. Use one of the built-in templates to get started (alternatively add packages/<new-package> files manually):

    npm install
    npx yo @visma/visma
  3. If the package has files to be deployed to GitHub Pages, add paths to ci.yml

  4. When you are ready to publish, run npx changeset and follow the instructions, then create a pull request. CI will publish a new version from the main branch according to the changeset.

Package guidelines

  • Make sure there is not already a package for the same purpose. Really, there are packages for almost everything on npm.

  • Keep the number of features small. A small package is more composable and usually has more real world use cases, then a package that does multiple things.

    Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

    — Antoine de Saint-Exupery

  • For other than tools, always use TypeScript or add types manually

Naming

  • Every package must use the @visma scope
  • If the package is for a specific technology, prefix with that. Examples:
    • @visma/react-foo
    • @visma/babel-preset-bar
    • @visma/angular-baz
    • @visma/mui-qux
  • If the package is an integration between external packages, list names alphabetically, join using kebab case, and suffix with -integration. Example:
    • @visma/msw-openapi-backend-integration

Versioning

Follow SemVer. Also, it is recommended:

  • 0.1.0 to be the first release
  • For the first year keep versions in the 0.y.z range, where y: breaking changes, z: other changes
  • Release 1.0.0 1 year after the first release, regardless of the change. This ensures the public API has time to be defined, and the package won't stay years in the initial development phase.
  • For breaking changes use React’s approach. In short:
    1. In a minor version update:
      • Introduce new APIs and breaking changes using a different name, example next_someFunction
      • Deprecate someFunction
    2. In a major version update:
      • Rename next_someFunction to someFunction (keep next_someFunction available too)
      • Deprecate next_someFunction
    • Benefits:
      • Functionality can be changed within one major version bump 👍
      • Users can always upgrade to the next major version, if they have first upgraded to latest minor version and are not using deprecated APIs 👍

Readme

README.md is required. If applicable, readme should include at least a usage example and documentation of the public API.

Install instructions or other general information should not be included, unless there is something special to mention.

Changelog

Include a CHANGELOG.md file (example).

Tests

package.json may have a test script. CI makes sure tests are passed before publishing.

Help / Contact

In any questions or suggestions, feel free to reach out to @ArnoSaine.

About

Tools, snippets, helpers and other utility packages by Frontend discipline and contributors.

Resources

Stars

Watchers

Forks