Visma

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

Contributions are welcome!

Packages

Plugins & Presets

• @visma/babel-preset-formatjs – babel-plugin-formatjs with removeDefaultMessage set true in production
• @visma/craco-plugin-super-template – CRACO plugin for @visma/cra-template-craco-super-template
• @visma/vite-plugin-super-template – Vite plugin for super-template

Templates

• @visma/cra-template-craco-super-template – Create React App template with multiple preinstalled libraries and predefined configurations

Tools

• ~@visma/build-npm-workspace – Build npm workspace packages in the correct order of internal dependency graph~ (deprecated)
• @visma/christmas-elf-name-generator – With this high-level neural network -assisted Christmas Elf Name Generator, you can now generate your own custom elf name just in time for Christmas!
• @visma/formatjs-scripts – Extract and compile messages, scan node_modules for messages
• @visma/generator-visma – Yeoman npm package generator for this repository
• @visma/react-openapi-client-generator – Generate typed hooks and methods for React app from OpenAPI schema
• @visma/remix-ssg – Generate static site from Remix app

Helpers & Utilities

• @visma/msw-openapi-backend-integration – Helper to integrate Mock Service Worker with OpenAPI Backend
• @visma/react-app-locale-utils – Locale state, display names, date-fns, MUI and other locale utilities
• @visma/react-app-super-template – AppProvider for super-template
• @visma/react-intl-bundled-messages – IntlProvider that lazy loads messages in current language in Webpack environment
• @visma/react-keycloak – Keycloak helper components, hooks, etc.
• @visma/tailwindcss-vud – Visma Unified Design theme configuration for tailwindcss
• ~@visma/tailwindcss-nordic-cool – Nordic cool theme configuration for tailwindcss~ (deprecated)

Configs

• @visma/eslint-config-super-template – ESLint configuration for super-template
• @visma/public.config – Public build, deploy & runtime configs in globalThis.ENV, dynamic by hostname
• @visma/tsconfig – Shared base TSConfigs

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.