coder-spirit / nominal Goto Github PK

Introduce new tests to assert this property. Might be the case that it does not hold in the current situation (at least before we implement the issue #2 ).

• WithTag<WithoutTag<WithTag>> === WithTag // We want to test this because WithoutTag is relatively complex

At build step, generate ESM files as well, and export them property through package.json.

For more info (follow links in document): https://docs.skypack.dev/package-authors/package-checks

Right now, we use the properties __baseType and __typeTags to hold the typing information. Using symbol entries instead of strings would be safer.

• Use "symbols" instead of __baseType and __typeTags.
• Mark the typing properties as readonly.

The installation instructions in the nominal README state to use npm install or yarn add --dev. The npm install instructions will add nominal as a production dependency whereas the yarn install instructions will add nominal as a dev dependency. This seems inconsistent. How should we install nominal? regular dependency or dev dependency specifically when the nominal branded types will be added to a library that will then be re-used by multiple downstream dependencies?

Thanks and appreciate the great work on this incredibly useful library.

• Buffer
• arrays

Introduce BaseType helper to extract the base type of branded/tagged types.

Make it compatible with Deno, and publish it wherever Deno users pick their libraries from.

• Resolve issue #11 first.
• Ensure that imports have extensions
• https://denopkg.com/
• https://deno.land/x/
• https://nest.land/

More info here: https://dev.to/craigmorten/how-to-publish-deno-modules-2cg6

In order to improve composability, WithoutTag should be split into two types, one keeping the old name, but without the "tag negation" effect, and a new one that explicitly negates the tag.

Stick to a fixed terminology. Right now we use the terms "tag", "type" and "brand", we should clarify how we use them and simplify as much as possible the terminology.

• Branded types.
  • compatible with multiple tags
  • but only one brand is possible per type
• Flavored types. Like branded types, but less strict:
  • they don't accept differently branded values
  • but they do accept values of the "naked" base primitive type

Ensure that tests & linters are executed on pull requests.

Separate type definitions into multiple files to improve readability

• CONTRIBUTING.md: We should have a document explaining the workflow of this project and how to contribute.
• badges: add badges to README.md to signal project quality.
• funding: unlikely that will be useful, but it would be nice that people can be thankful for the effort.

Add inline documentation for types, to be shown by intellisense in IDEs.