Aucune remarque pour cette diapositive
Intro: units of code reuse.FunctionsModulesPackages
I work at Lab49 in NYC with smart people.
“Code dependency” is a very low-level thing. Functions express code dependencies too; modules are only slightly higher level than that (and sometimes at the same level)AMD is definitely better than nothing, so I won’t fault you for using it. But as you’ll see, it’s the worse option for apps that need true code reuse.
AMD has leaned on excessive configuration to solve problems that are best solved by a package management system/In a CommonJS system alone, require('a') is meaningless---because module systems are just about files!
Large projects will always want to break themselves up into reusable pieces at a larger level than just modules. Third party dependencies are a great example. But how do you express that kind of dependency in AMD?
Problems beyond a module system: that’s why the config exists. Shims, baseUrls, packages, maps… Especially plugins. Modules should just be files!So. These problems should not be solved at the module level. Where should they be solved?
By using CommonJS, we’ve solved one level of code reuse, without overstretching
I mean “our own code” very literally---I think without packages, you can’t scale beyond a single person.
Can you imagine not having to go back to their site, re-input what you had before, click the new box, download the file, overwrite the last one, and check it into source control (even though it’s not code you authored)?
The first two are solved by the package manager, a command-line program.The third is solved by mapping package names to their main modules.The fourth is solved by a central registry.
26K is important, because package ecosystems are heavily empowered by network effects. Small packages can still be powerful in an ecosystem like that.
You can have a header widget coded in Backbone and Stylus, while your folder list widget uses jQuery UI sortable and SASS.The single entry-point API makes it easy to create simple interfaces and contracts, e.g. “exposes a render method that returns a document fragment” or similar.
npm test = a universal format for testing packages, no matter how they were authored
Let’s get this out of the way.
Npm gets packages onto your computer; browserify gets them from their into your browser.
This is the .travis.yml for client-side packages.You can use “harness” OR anything that outputs tap
You want to reuse code? Do these things.