Rethink the index barrels since they now need to be part of the import (e.g. `@/db/index.js`)

[cerinoligutom]

Now that #45 thru #73 has been addressed. Have to rethink those index files as they look ugly being explicitly declared now everywhere along with the file extension name. Should this be kept or removed then have more imports? 🤔

Back in CommonJS, given a directory

/src/db/supporting.ts
/src/db/files.ts
/src/db/here.ts
/src/db/exported.ts
/src/db/at.ts
/src/db/index.ts # Assume this is an index barrel that re-exports all the files above
/app.ts

We could import the index file from app.ts as:

import { supporting, files, here, exported, at } from './src/db';

But this doesn't work with ESModules and now have to be imported as:

import { supporting, files, here, exported, at } from './src/db/index.js'';

Which I find ugly.

I could go for a directory structure like:

/src/db/supporting.ts
/src/db/files.ts
/src/db/here.ts
/src/db/exported.ts
/src/db/at.ts
/src/db.ts

But this'd mean having a TS/JS file with an accompanying folder with the same name if there are supporting files. Take for example:

/src/dir1/**
/src/dir2/**
/src/dir3/**
/src/dir4/**
/src/dir1.ts
/src/dir2.ts
/src/dir3.ts
/src/dir4.ts

Just to avoid the index.js everywhere while looking succinct when imported.

[kutsan]

You can maybe try something like this https://www.npmjs.com/package/extensionless?

[cerinoligutom]

Hey, thanks for the suggestion @kutsan. Wouldn't this only solve the build and runtime issue? TS on IDE would still complain.

And if I understood correctly from reading ESM, it's just how it works and there's no way to omit it. Wondering if there are new patterns emerging from this enforcement or there's a "proper" way of doing it while satisfying the rest of the ecosystem.

There's the --experimental-specifier-resolution flag from Node and in turn a ts-node flag but since it's still experimental, I wouldn't count on it.