search

filecoin-station / spark-stats

API exposing public statistics about Spark
Other
0 stars 1 forks source link

observer: remove empty `index.js` #150

Closed juliangruber closed 4 months ago

juliangruber commented 5 months ago

This is convention that we have in other repos.

I stumbled over this blank index.js file a couple times.

juliangruber commented 5 months ago

Ok let's discuss!

I think this PR makes it already better as before, as at least there's some content in index.js. We could also remove it instead, I'd be happy with that too.

What would you propose?

What do you think about creating a miniature top-level index.js file that re-exports the public API from different lib/*.js files?

Are you talking about lib repos, or service repos like this too? What would be exported?

bajtos commented 5 months ago

I think this PR makes it already better as before, as at least there's some content in index.js. We could also remove it instead, I'd be happy with that too.

What would you propose?

Oh, I didn't realise we have an empty index.js file now. I prefer to remove it then.

Alternatively, in line with what I am writing below, we can put this code into index.js:

export * from './lib/platform-stats.js'

Although, that feels like adding an unnecessary redirection layer since we don't expect anybody to import from this package. I think it's better to remove the index file and let the bin script import directly from lib files.

What do you think about creating a miniature top-level index.js file that re-exports the public API from different lib/*.js files?

Are you talking about lib repos, or service repos like this too? What would be exported?

I didn't think about this much. When the package needs more than one source code file, I prefer to put everything into lib so that all files are together.

I think such an approach works well for services, where "bin" scripts can import directly from various "lib" files as needed.

For a library, it makes sense to have a single index file exporting the package's public API. I like to keep this index file minimal; it should just re-export stuff from other lib files.

I would even consider placing such an index file into lib/index.js, but the top-level index.js location also works since the public API (and this file) should not be changing too often.

Also, conceptually, it seems in a weird limbo state. bin files and lib files have nice conceptual narratives as to their function, and index.js not so much (most of it can semantically fit into the lib folder quite well I think, from what I am looking at our various services)

I love this framing - lib files implement the functionality, and bin files wrap that functionality into CLI/service executables. 👍🏻