Merge level and level-browserify

[ralphtheninja]

The only difference is that level-browserify has a browser.js which pulls in level.js. What do you think of merging them into one, e.g. deprecating level-browserify and adding level.js to level?

It would mean less to maintain and also simple to use level and it "just works".

Upcoming version of level will bundle levelup@2, together with encoding-down and have a promise layer as well, for people that prefer that.

cc @Level/owners

• Release level-browserify@2 first so we can get some testing

[mcollina]

I'm 👍 on that. Can we add level.js to the org itself? It might need some maintenance as well.

[vweevers]

+1 in principle and +1 on adding it to the org. But yeah, it might take some work to get it up to par with levelup@2. Don't underestimate that :)

[ralphtheninja]

@vweevers Currently I'm full time on level so am willing to spend time on it! Also @juliangruber is helping out.

[ralphtheninja]

After updating myself on the code, I've realized that it's actually level-packager that pulls in levelup and that should also pull in encoding-down. Just fyi.

[ralphtheninja]

I think we should release level 2.0.0 first. The work on level.js will take a lot of time and we can release that as a minor once the new major is out.

[huan]

+1

level should be the first choice for the user because its name is short and straight forward.

Make level better and let it replace level-browserify and level.js seems a good idea for me.

And I'd like to suggest to rewrite level module from JavaScript to TypeScript because it will be very easy to integrate with the typings from levelup and leveldown.

[vweevers]

And I'd like to suggest to rewrite level module from JavaScript to TypeScript because it will be very easy to integrate with the typings from levelup and leveldown.

Big -1. The primary audience consists of JS users.

[huan]

@vweevers I agree that we must always make the JS users happy.

However, write in TypeScript will NOT change anything to the end JS users.

All JS users could still use the module by npm install and const level = require('level') without any problem.

The only difference is that we write in TypeScript. And we compile the module to JavaScript before we publish it to NPM.

So please don't worry about that, JS users will stay happy with JS. :)

[vweevers]

The audience also includes the maintainers and contributors that write this code :)

Speaking for myself: I don't know TS, nor am I interested in it at the moment. I would very much like the core of the Level ecosystem to stick with JS as the primary language. This probably also goes for @ralphtheninja, @juliangruber and a whole bunch of other people here.

That's not to say we can't accommodate TS users. We are more than happy to include typings and I applaud the amazing work that @MeirionHughes and yourself have done so far and will do 👌

[huan]

@vweevers I fully understand your feelings.

TypeScript did not feel good at the first look, I even feel very bad when I saw Angular(Angular2) only provide the documents with TypeScript.

But after trying it a little bit, I start to know how it could make the developing job more easy and robust.

Here's a great introduction video of TypeScript by Anders Hejlsberg at https://channel9.msdn.com/Events/Build/2017/B8088/, would strongly recommend taking a look.

[MeirionHughes]

@zixia I think the maintainers here are die-hard js fans.

I don't see the harm in starting new repositories as typescript, but think moving this entire eco-system over is a huge undertaking and will be painful to ensure nothing breaks.

Right off the bat, you won't be able to do the commonjs + es2015 default export hack. ts will simply complain about it if you try to do both. We're getting away with it at the moment because its just the typings that have gone with only the es2015 module.

Currently, its all prototype based too and quite well supports the older systems. If you have typescript try to "down-compile" you'll get a considerable amount of code-bloat... or a dependency to tslib