Misc Playground/Docs fixes
This commit is contained in:
+13
-2
@@ -77,7 +77,7 @@ These guidelines represent best practices. While exceptions may occasionally be
|
||||
- Often mask underlying issues that should be properly resolved
|
||||
- Can lead to unintended side-effects throughout the codebase
|
||||
|
||||
4. Avoid additional dependencies.
|
||||
5. Avoid additional dependencies.
|
||||
|
||||
Try to avoid pulling in additional packages. Not only can this bloat the project, but can also cause compatibility issues between environments (Web, Node, ESM, etc). We want `@xocash/stack` to "just work" without devs having to tailor build configurations.
|
||||
|
||||
@@ -87,7 +87,18 @@ These guidelines represent best practices. While exceptions may occasionally be
|
||||
- Does not drag in additional dependencies itself (note that `devDependencies` are fine. These will not be installed when leveraged from our packages).
|
||||
- If the package being used **is heavy** and we have no other choice but to use it, consider whether we should package it separately to avoid problems. For example, if we build a `BlockchainBCHN` adapter, we will likely want to package this on its own under `@xocash/blockchain-bchn` as it only works in NodeJS environments.
|
||||
|
||||
5. "When in Rome..."
|
||||
6. DO NOT use Typescript "enums".
|
||||
|
||||
TypeScript enums have several issues that make them problematic:
|
||||
|
||||
- They generate unnecessary runtime code and don't tree-shake well, increasing bundle size
|
||||
- Numeric enums allow unsafe reverse lookups and can be assigned any number value
|
||||
- They don't work well with module augmentation and can cause circular dependency issues
|
||||
- They're not compatible with Node.js's --experimental-strip-types feature, which only removes type annotations and doesn't transform enum syntax
|
||||
|
||||
Recommended alternatives: Use const objects with `as const` assertions or string literal union types instead, which work seamlessly with Node's type stripping.
|
||||
|
||||
7. "When in Rome..."
|
||||
|
||||
For conventions not explicitly mentioned, follow the "when in Rome" principle. Try to identify and use the patterns and conventions that are already established elsewhere in the codebase.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user