Restructure market-cap repo to avoid `index.ts` conflict

[longngn]

Currently index.ts get conflicted a lot if we don't merge PRs for a while because everyone is updating it
Maybe we can refactor to like cardano-token-registry where each token is a file with its policyId + assetName be the file name, and the file will export default the fetcher

WDYT @MuesliSwapTeam @TheTapHouse @shadowkora

[MuesliSwapTeam]

We were noticing the same, not sure how smooth JS can handle integration of a "loose bunch" of JS files :) We do also rely on some way to easily assess all tracked tokens, i.e. if a map is generated on the fly that holds as keys all the tokens that are tracked thats perfect for us.

[longngn]

We were noticing the same, not sure how smooth JS can handle integration of a "loose bunch" of JS files :) We do also rely on some way to easily assess all tracked tokens, i.e. if a map is generated on the fly that holds as keys all the tokens that are tracked thats perfect for us.

Currently we don't use npm library anymore, we just pull the latest commit and run internal/main.ts
If we do 1 fetcher = 1 file, then the script we can iterate through all files and dynamically require/import that module and run it

if you still want npm package, I can extend the build process to generate index.ts and build it

[MuesliSwapTeam]

An autogenerated ´index.ts´ sounds good - after all the structure of the file is really straightforward.

[mezuny]

If the structure is being changed as is, why not change token entries in /src/tokens/ to be .json files with a set structure to make it more accessible (and less prone to errors) for projects to modify these files? Feels like a import all .json files on the tokens folder would do the job, with a simple structure that takes care of all variables.

[longngn]

If the structure is being changed as is, why not change token entries in /src/tokens/ to be .json files with a set structure to make it more accessible (and less prone to errors) for projects to modify these files? Feels like a import all .json files on the tokens folder would do the job, with a simple structure that takes care of all variables.

yeah I'm also thinking about that but afraid that we can't accomodate to all projects' need, maybe a project has an adhoc formula