NPM / Bower

[mattdesl]

It would be great to have better support for Zepto in some form of package manager. Ideally, I would love to have it on NPM like so:

npm install zepto --save

With browserify, I can then easily do something like: var $ = require('zepto');

Many browser-specific modules are making their way into NPM with great success. Some examples: jquery, domready, xhr, and hundreds more. Package managers are helping JS and the web move forward; solidifying things like semantic versioning and dependency management, and making apps more modular and lightweight. The old way of "Download this file and copy-paste it into your vendor folder, and check back regularly for updates" is antiquated, and will hopefully die off completely in a couple years.

Zepto has shut this idea down in the past; but I'm reopening it because of how important it is for the future of this library. I think some different options should be explored before closing anything.. And although I prefer NPM, really any sort of package manager support would make Zepto easier to consume.

Here's a few different ideas:

• Include a build in version control, and add a bower/package JSON which points to the build. Users can install the GitHub repo without having to build or setup any Zepto paths. This requires no changes to Zepto source, and doesn't require managing NPM versions. Users would know that it needs to be shimmed since it doesn't live on NPM (e.g. using debowerify or browserify-shim).
• Explore how jQuery is building its releases. It only includes the build files in tagged releases; which allows it to easily be consumed by NPM/Bower. Otherwise the build is not versioned. Same as above: no source changes or NPM versioning.
• Use gitignore so that the latest build isn't versioned, but can still be pushed to NPM. This requires managing NPM versions and having the build support CommonJS exports (since it lives on NPM, it's expected to work with it).

The third option would lead to minor source changes and NPM management. A quick rundown of how that might work:

1. Add module.exports = Zepto at the end of the (unbuilt) source
2. Now say you patch a feature of Zepto and want to update NPM and GitHub:

git commit -m 'patched X feature'
npm version patch
npm publish
git push --tags

This publishes the patch to NPM. Users installing or updating Zepto will automatically get the patch since it's not a major version change. It also creates a new git tag with the new version number, which you can then push to git.

Then, to support non-NPM users, you would use a tool like browserify with the standalone option when building Zepto. This will wrap the module.exports for you, so the code is compatible with CommonJS, AMD, or any non-module system (i.e. regular <script> tags). More info

[mislav]

https://github.com/madrobby/zepto/pull/578#issuecomment-8386835 https://github.com/madrobby/zepto/pull/872#issuecomment-29538510 https://github.com/madrobby/zepto/pull/949#issuecomment-40263399

Every option that you've described is a lot of work for us to do and maintain, and we're simply not motivated to do any of that since we don't use NPM or Browserify for our client-side stuff. What jQuery does with its releases is a huge hack and abuse of the version control system. They had to force-push existing tags, for god's sake.

Zepto is already easy to obtain.

[mattdesl]

Easy to download, sure, but not easy to consume, and certainly not easy to manage as a dependency (e.g. versioning).

Nevertheless, if you still haven't found the wonders of package managers I can understand why any changes might seem annoying or unnecessary. How about an option that doesn't lead to Zepto source changes, and makes NPM maintenance a non issue? For example, using Travis:

http://docs.travis-ci.com/user/deployment/npm/

This way, you do not need to maintain NPM since it's become automated for you. The only thing in this case would be to figure out how to build Zepto for NPM without affecting it for other users.

On Apr 22, 2014, at 7:00 AM, Mislav Marohnić notifications@github.com wrote:

578 (comment) #872 (comment) #949 (comment)

Every option that you've described is a lot of work for us to do and maintain, and we're simply not motivated to do any of that since we don't use NPM or Browserify for our client-side stuff. What jQuery does with its releases is a huge hack and raping of the version control system. They had to force-push existing tags, for god's sake.

Zepto is already easy to obtain.

— Reply to this email directly or view it on GitHub.

[mislav]

How about an option that doesn't lead to Zepto source changes, and makes NPM maintenance a non issue? For example, using Travis

That's a good suggestion. Technically, we could say that such an approach would solve the packaging problem. But philosophically I'm still opposed to use something called a "Node package manager" to manage faux CommonJS "modules" that are loaded in the browser (rather than the server) by means of hacks.

Zepto is oldskool JS. Drop it in your project, use it. For people who find this being too much work, they probably shouldn't use Zepto.

[josh]

Zepto is published on bower via the https://github.com/components/zepto repository.

[bevacqua]

@mislav npm doesn't stand for Node Package Manager, so there go your philosophical concerns.

I agree with @mattdesl. Turning a deaf ear to people using Browserify and npm (imo the best option out there, bower and requirejs suck far worse) to develop modular client-side applications does no-one any good, philosophy aside.

[mattdesl]

@josh The components/zepto repo (which Bower points to) is unofficial and will always lag behind Zepto updates. It also doesn't contain any of the tests, readme, or other goodies that you might expect to get when installing a dependency. It would be ideal if Bower pointed to the actual Zepto repo, rather than a 3rd-party shim/fork. :)

Zepto is oldskool JS. Drop it in your project, use it.

Lots of "old school" JS libraries (like jQuery) have been keeping up with modern practices by publishing to NPM/Bower. Package managers solve some fundamental issues with the old school approaches, like version and dependency management. Typical example: writing modular libraries that depend on Zepto.

Your stance seems pretty clear: Zepto will never officially support modern workflows, and is intended for "old school" developers. :-1:

[madrobby]

@mattdesl Please refrain from further commenting on this issue. Your comments are not going to change our stance on this. If you need this feature, it's easy for you to fork Zepto and augment it in whatever way you wish.

[mattdesl]

The nature of open source is that others will critique, contribute, and attempt to improve on your work.

But your disinterest in these changes has been made pretty clear, so I will drop it. :)