Deploy to meteor.com fails with error “Cannot find module 'websocket-driver'”

[steph643]

Any chance this issue might be specific to Windows?
http://stackoverflow.com/questions/24209486/deploy-to-meteor-com-fails-with-error-cannot-find-module-websocket-driver
Thanks,

[sdarnell]

Sorry for the confusion, but I thought it would be best to answer at the SO question.

Current situation is that when I (using 0.8.1.3 on Win7) publish an unmodified leaderboard example it works fine, for example: http://leaderboard_sd.meteor.com/ which suggests that there is some problem with your environment or installation of meteor.

I know it may sound a bit lame, but can I suggest that you try doing a re-installation or meteor on our machine? In Windows Explorer find %LOCALAPPDATA%\.meteor and delete it (or rename it if you prefer). Then re-run LaunchMeteor.exe.

Then, recreate a new leaderboard directory from the example (a fresh one):

    meteor create --example leaderboard leaderboard_new
    cd leaderboard_new

The other thing that I did (which I don't think should make a difference) is that I launched it locally before publishing to meteor.com.

Finally, just for reference, what OS are you using, again I don't think it makes a difference but it is sometimes useful (Win7, Win8.1 etc.)

[sdarnell]

The other avenue of attack is to see ho your bundle differs to one that I generate. For reference, my output of meteor bundle is https://drive.google.com/file/d/0B4Vwungdd_-RUXdUcWMyUzllU0U/edit?usp=sharing

[steph643]

Thanks a lot for your answer.

Here is what I have done:

1. Deleting %LOCALAPPDATA%\.meteor
2. Downloading LaunchMeteor.exe from http://win-install.meteor.com/LaunchMeteor.exe and installing
3. Creating a new leaderboard project
4. Running it locally successfully
5. Deploying it to a new address
   -> Still the same issue

I will now compare my bundle with yours.

[steph643]

My environment:

• Windows 7 Professional SP1
• Macbook Air

[steph643]

Got it. The problem is caused by long file path. It seems `Meteor deploy' silently fails when paths are too long. If I create my Meteor project closer to my root directory, it deploys like a charm.

[steph643]

I confirm the above. Bundle comparison shows that all files deeper than ~12 nested folders in the file hierarchy are not present in my bundle.
I suggest I answer my StackOverflow question. Or do you prefer to do it? (I would credit you with the answer)

[sdarnell]

I added an answer to the SO question suggesting using shorter paths, but I will leave this issue open and investigate why the bundler is ignoring some paths (it shouldn't, and certainly shouldn't do ignore them without a warning or error).

I'm really glad you have a work-around for now :)

[steph643]

Great, thanks again.

[sdarnell]

I did have a look but didn't spot anything obvious - but I'll have a better look after 0.9.

[steph643]

Thanks.
Speaking about 0.9, any clue about the release date? :-)

[sdarnell]

Soon :)

[sdarnell]

I've just been re-testing this issue with 0.9.0.1 and it still exists.
To repro it I created two copies of the leaderboard example app, in the following directories:

1. c:\meteor\leaderboard
2. c:\meteor\nested1\nested2\nested3\nested4\nested5\nested6\nested7\verylongdirectoryname_verylongdirectoryname2_verylongdirectory\leaderboard

When I then use meteor bundle --directory c:\tmp\leaderboard1 both produce the same output.
But when I generate tarballs the results are different:

Which suggests that the bug is in the tarball generation or node-tar rather than npm.

[peterennis]

Or this long discussion:
nodejs/node-v0.x-archive#6960
leading to this decision:
nodejs/node-v0.x-archive#6960 (comment)

It is reported that gitbash (tar) > 1.9 can deal with the long structure.

[sdarnell]

Thanks for those links @peterennis It would be amusing if it weren't so sad.

In this case though, it appears that although the node_modules stupidity is the initial cause in this case, I believe the underlying bug is with the process of generating the tarball. NPM lays down the files just fine (when using the --directory option). The good news is that the tarball process is much easier to debug/fix than npm.

We currently use node-tar and as node/UV supports long file names it should be OK, and I really strongly do not want to depend on external utilities such as gitbash unless absolutely necessary.

[sdarnell]

Aha, I've found the problem - fstream has a really nasty windows specific bug, and this is used when building tarballs (and possibly other things).
See npm/fstream#30