-
Notifications
You must be signed in to change notification settings - Fork 210
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
Question on project structure #6
Comments
Yes, this the big question I'm trying to solve (and suggestions welcomed). In the previous iteration all the modules were exposed in the tonal npm package. But this approach has some problems, like the one you're showing here: it's no easy to know what's inside and how to access. Also, the package size is quite big for a library that (I think) is focused mostly for browsers. My preference for this iteration is expose only the following packages in
All the functions would be exposed without scope: tonal.transpose, tonal.range ... That means that packages like scales, chords, keys would be necessary to import them explicitly: var scale = require('tonal-scales')
scale.fromName('C major') This is what I have in mind right now, but I'm open to suggestions. I hope it helps. Cheers. PS: both |
Hi, just to show (instead of describe) what I'm thinking I've added a first version of the tonal package to the repo. You can take a look to the source code here: https://github.com/danigb/tonal/blob/tonal-0.50.x/packages/tonal/lib/index.js Ideas are welcomed. Cheers. |
Hey Dani, Here's what comes to mind: If you decide to only expose a couple of the packages, isn't the criterium of which ones to select a bit subjective? I mean, I would sooner expect note, interval and chord to be included than the others, but that's just me. Another user may have different needs. It feels a bit ad hoc to me. And if file size is the main reason for limiting the number of packages, then one could consider that (possibly) tree-shaking will become standard in the bundling tools. I know Webpack2 will have it, and Rollup has of course ... (I don't know about Browserify or jspm). But this may not be a very robust assumption right now. The other issue is wether to export functions or entire modules. If you export functions, won't you loose the benefits of namespacing? All the method names will have to be unique across all the packages. But perhaps that is not a big problem in functional programming. Well, those are just a few thoughts, I hope it's useful! |
Hi Rob, Thanks for the detailed feedback. It's really appreciated. I try to answer (also to me) some of the concerns you arise:
Yes, in some part is quite subjective. While I was developing tonal I keep learning new stuff from tonal music theory and wondering if I should put in the library or not. Binary scales, for example. It's not very known, but helps a lot with chord and scale detection. Or interval density to compare consonances or disonances... So, at some point I had to stop. Or I feel, at least, I have to stop growing the library (and instead add module extensions), and where to stop is subjective. But on the other side, I found that some modules (keys, scales, chords, progressions) always require the same functionality (the one I want to include...)
It's true that there are tools to help with file size, and thats one of the reason to move to ES6 and rollup. But currently they are all in early stages and they don't give a very pleasant user experience (learn webpack configuration is tedious, and rollup results are not always optimal by my own experience). For me the point is to find a balance between simplicity and useful. I have to admit that I was thinking to keep Also, I want a source code people can understand (one of the complains of the last version), and I think that reducing the size, helps in that direction. I even also tried to make a simple
Yes, but I feel that this constriction help me finding good function names ;-). But, of course, limit the amount functions included in the tonal package. Also I dislike the big resulting names like
My idea was to expose the full module (not only parts). And yes, my experience with functional programming is limited (in fact, this is my first attempt to write a library in a functional style) and JavaScript is too flexible ;-) So at the end, what I like is a good user experience: you should be able to require
May I ask... what would be a good user experience to you? Thanks, |
Hi Dani, I can certainly understand your reasoning. Keeping your library light-weight and easy to set-up is indeed an important consideration. More in general, about my user experience, the first thing I noticed about tonal is the documentation. I think you are very right to emphasise it the way you do. As javascript developers we have to dig through dozens of libraries nowadays, and a complete and up to date documentation is really helpful. I also think it is a sign of how serious a library author is about maintaining the library in the future. cheers, Rob |
Hi Rob, Thanks a lot for your detailed feedback. It's really appreciated. I new version of tonal is coming, and I'll consider your opinions. Good luck with your fretboard app and don't hesitate to ask if you have any problem with tonal. Cheers, |
Hi, Finally for the 0.50.x release I decided to include a selection of modules in |
I was wondering how the main
tonal/lib/tonal.js
file relates to the individual packages. I don't see how they are connected. Will usage be like:and/or:
The text was updated successfully, but these errors were encountered: