Please remove "dist" from .npmignore

[udondan]

I'm the maintainer of a package* which packs jszip for the Meteor framework. Meteor has the option to set dependencies from npm, which I do.

The package adds zip functionality to server and client. The server side implementation relies on the npm module. For the client side implementation I simply sent the file dist/jszip.js to the client, which now is not possible any longer. Any chance you remove that folder from the .npmignore? I see how it's not required in a standard node setup, but it doesn't hurt to have it and enables me (and other users/maintainers) to ship the file directly to the client.

* Please don't think this doesn't matter because the package is listed with zero downloads. Meteor just changed its package management system which reset all counters to 0. I just updated my package to be compatible with the new system. Before it had several hundred downloads. :)

[Stuk]

The thing is, all the npm package is the distribution and so it makes no sense to include the dist files as well. The dist files only exist because it's expected that Javascript libraries are available to download as one file.

Does meteor not provide a build step/runtime for client side CommonJS dependencies?

[udondan]

No, there's no such thing I'm aware of.

A manual build step between adding the package and starting the app would be against the principle of simplicity. Furthermore the user wouldn't know about it if my package comes as a dependency of another package.

And I think at run-time it won't be possible as in many cases Meteor won't have write access to the file system. That's because Meteor comes with free hosting included, though there are limitations for security reasons.

Just to understand what needs to be done, how would one build the dist files from the files in the npm package? I think I would have a hard time to work through all the require statements.

[Stuk]

Okay.

It's pretty straight forward to build.

# if you don't have grunt
npm install -g grunt-cli
grunt build

[udondan]

Thanks Stuart. But that is no option for three reasons:

1. Not 100% sure about this, because everything I know from grunt is what I have read in the past 5 minutes: The Gruntfile.js is too, listed in the .npmignore, so I guess I couldn't even build the file from the npm package if I wanted to, right?
2. The user does not have access to the jszip folder. After installation of the package it's hidden somewhere in the Meteor internals, not in the project files. The user should not touch those files.
3. If I require the user to install grunt and run a command (every time the packages might update), that simply brings the installation process to absurd lengths. It would be more easy for the user to simply download the file and save it manually in the user space of the app instead.

So I don't see a manual build process as reasonable and an automated one through grunt not possible for mostly the same reasons (don't touch internals, no write access on remote servers) plus grunt not available. ...plus a huge overhead in maintaining a package which simply should add one single js file to the client.

The only reasonable and very ugly solution I see on my end is to actually pick that single js file and physically put it into the package instead of just adding a dependency to the npm module. A git submodule might be more easy to maintain but would add redundant download of the stuff which already is there from the npm module. And the git submodule itself can not be used the way the npm package is bundled. (e.g. there is no require in Meteor and the code would throw errors)

The thing is, all the npm package is the distribution and so it makes no sense to include the dist files as well. The dist files only exist because it's expected that Javascript libraries are available to download as one file.

I understand that and appreciate your sense for cleanliness. But I have a real use case here. :)

BTW, why do you have the vendor folder not listed in the .npmignore? I can not see it being used anywhere in the library, only in the documentation/examples. Is that intended?

[kand]

I agree here, it doesn't make sense to omit the dist directory from the npm install... This makes the package essentially unusable in its compiled format if you're installing via npm.

[toddhalfpenny]

Looks like this change was made, though no release has been created since. I'm currently using this command

npm install https://github.com/Stuk/jszip.git#bcfe0352bfd0d3c93251b68eaebe77109e34a25f --save-dev

Dead handy repo, BTW, thanks.

[Protectator]

Agreeing on this too. This makes no sense to ignore the dist directory in an npm package. I want to use it and have to manually install the dependencies (>100Mo actually) just to be able to use the library.

Edit : Ok I went a bit too fast and didn't see that this change was already on the git. Now what needs to happen is an npm release to actually make this change useful. :)