feat: @ckb-ccc/molecule

[Alive24]

Splitted commit for demo

[changeset-bot]

⚠️ No Changeset found

Latest commit: 38c4e95

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Hanssen0]

Thank you for the contribution. However, the style of this code is not good enough to be merged into CCC. Issues include:

1. Inconsistent naming - getCodecMapFromMol/createCodecMap's logic are almost always parsing something, but using different verbs. nonNull as a function, it has no verb in its name, and also different from assert... functions like assertFixedMolType. Moreover, we have check... functions that return nothing, basically assert... functions.

2. Non-descriptive names - Names like refs force devs to look into the code to tell what it is. Others like toMolTypeMap.results give us a wrong description - it's an argument, not a result.

3. Performance - This is the least important issue. But still, MolType[] is converted to MolTypeMap multiple times, and some assertions like assertFixedMolType might happen more than once in a single type.

[Hanssen0]

I expect the improved version and will review the demo code after that. In the meantime, the first commit modifies pnpm-lock, but CI seems to have some problems. Please check.

[Alive24]

Thank you for the contribution. However, the style of this code is not good enough to be merged into CCC. Issues include:

1. Inconsistent naming - getCodecMapFromMol/createCodecMap's logic are almost always parsing something, but using different verbs. nonNull as a function, it has no verb in its name, and also different from assert... functions like assertFixedMolType. Moreover, we have check... functions that return nothing, basically assert... functions.
2. Non-descriptive names - Names like refs force devs to look into the code to tell what it is. Others like toMolTypeMap.results give us a wrong description - it's an argument, not a result.
3. Performance - This is the least important issue. But still, MolType[] is converted to MolTypeMap multiple times, and some assertions like assertFixedMolType might happen more than once in a single type.

Names changes are made. Functions are refactored to keep pure and MolTypeDefinition is not converted to MolTypeMap any more and assertions are also improved.

[Hanssen0]

This version is way better than the last one! Everything is understandable now.

I commented with some questions and suggestions that might help us improve. Please check.