Visma

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

Contributions are welcome!

Packages

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

~~@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

@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)

@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

Clone this repository
Use one of the built-in templates to get started (alternatively add packages/<new-package> files manually):
```
npm install
npx yo @visma/visma
```
If the package has files to be deployed to GitHub Pages, add paths to ci.yml
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.

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

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

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.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.

Include a CHANGELOG.md file (example).

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

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