-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decide on naming of modules #6
Comments
Option 3, where
1 Would export |
Not really an option to me, when it doesn't make sense for everything to be called
I think this is the best for consumers, but I wonder how we would do that. If we moved the code, we'd lose history, if we renamed the repos people might be confused.
Prefixes are nicer because they sort well 🤔 |
The best (but indeed not perfect) way would be to rename The potential confusion is why I'm leaning towards option 3 atm, because it makes a clean split. Consumers will have to replace their
It's a crowded namespace so we'd have to use an npm |
It will be confusing either way, so I'm also leaning towards option 3, to make it less confusing. New names also makes it easier to talk about different things. |
As for Click to expand✖ sublevel (https://www.npmjs.com/package/sublevel) is unavailable |
Here's a complete set of names. Unique enough, available on npm, and able to distinguish between the name of the
1 Will export |
To clarify that "Named export" column, I'm also thinking of using classes and named exports everywhere. E.g.: const { ClassicLevel } = require('classic-level')
const { MemoryLevel } = require('memory-level')
const db = new ClassicLevel('./db', { valueEncoding: 'json' })
const db = new MemoryLevel({ valueEncoding: 'json' }) This makes TypeScript typings easier (cc @MeirionHughes) as the main class can only be called in one way (with export class ClassicLevel {
// ...
}
export interface ReadOptions {
fillCache?: boolean | undefined
} |
Closing as "resolved". If you have objections please raise them soon, because after landing #8, I'll release |
With
abstract-level
, there is no "down" or "up" anymore. For example,memdown
does not have to be wrapped withlevelup
. This meanslevel-mem
could just domodule.exports = require('memdown')
to export (largely) the same functionality as before. Which begs the question, should we:memdown
(as anabstract-level
database); deprecatelevel-mem
(as alevelup
db)memdown
(as anabstract-leveldown
database); move code tolevel-mem
(as anabstract-level
db)memory-level
package (as well asleveldb-level
,indexeddb-level
, etc)@Level/core thoughts?
The text was updated successfully, but these errors were encountered: