Bower quick start fails.

[treasonx]

I tried to run through the bower quick start, because i'm old and i like AMD :)

I think rave might be broken in anything but CommonJS module formats.

When I run my hello world rave app I get the following error:

-> Type rave() to turn on REPL commands. (experimental) debug.js:72
Unknown package when importing fs from rave@0.1.3#rave/rave
Did you forget to specify `--save` when installing? debug.js:112
Uncaught Error: Package not found for fs createVersionedIdTransform.js:26

http://cloud.trx.tips/VqVj

It looks to me like it was looking for the fs module which doesn't exist. I dug a little further and found in the rave bower.json file that it specifies moduleType as node. https://github.com/RaveJS/rave/blob/master/bower.json#L6 So i decided to remove that line cause I have nothing better to do and then it goes on to cause more errors related to an undefined Loader. Looks like it couldn't locate a loader for the browser environment.

i have no idea what i'm doing

I switched over the the npm quickstart and it works as expected.

[unscriptable]

Hey @treasonx, we were able to reproduce that [bogus*] error message if we didn't specify a moduleType in the top level bower.json file. Is this, perhaps, what happened? If so, try adding "moduleType": [ "amd" ], to your bower.json and see what you get. :)

* Something unexpected happened when rave hit this situation: rave/rave.js got downloaded twice and was evaluated as if it were a node module. :) This is clearly a bug that I'll have to track down.

Also, we need to give a better error message when the moduleType is missing or set to an unsupported value in bower.json (and package.json).

[treasonx]

Ah, I was under the impression that rave would "figure it out", based on the fact that I am in a browser and I am using bower then I am probably using AMD. Maybe thats a little too magical!

[unscriptable]

I was under the impression that rave would "figure it out", based on the fact that I am in a browser and I am using bower then I am probably using AMD

I think this used to work. I'll leave this issue open to see if we can make it work again.

[KidkArolis]

This is now working again after the improved moduleType detection code was merged. However, it would be good to do a new release, so that the version of rave installed by bower install --save rave works out of the box.

However, if you follow the bower quick start instructions, but use CJS in main.js instead of AMD - things still break - rave.js is being loaded in twice and the second time it breaks due to the "fs" and "traceur" requires.

[unscriptable]

Hey @KidkArolis,

Thanks for checking on this! Also: we def need to do a release. Perhaps when we resolve the issue you're seeing.

I can't repro the issue you're seeing, actually. Here's what I did:

1. I followed the instructions at https://github.com/RaveJS/rave/blob/master/docs/quick-start-bower.md to get a working AMD/bower project started using the current master branch of rave.
2. I converted the main.js file to CJS by removing the AMD wrapper. (If I run at this point, I see errors, but no doulbe-downloads.)
3. I switched bower.json's moduleType to [ "node" ] and the app loaded correctly.

I guess you did something different?

[unscriptable]

Ah, if I remove moduleType altogether, I see what you are seeing. Here's what's happening:

1. rave's moduleType auto-detect mechanism only detects "amd", atm.
2. If it doesn't find an AMD code signature, it defaults to "globals".
3. Once it has determined that main.js is global, it looks in bower.json for dependencies and finds rave.
4. Since the rave/rave module isn't cached (this is a bug), it fetches it again, but this time the es6 loader code doesn't correctly detect that it's running inside a browser for some reason.

Seems we should nip this in the bud (number 1 in the list, above). Perhaps we should attempt to sniff for CommonJS-formatted modules? I was initially against it, but now I think it makes sense as a secondary mechanism. The primary mechanisms are a) explicit moduleType, b) npm heuristic that implies moduleType = ["node"].

Unless anybody objects, I'll add CommonJS sniffing asap.

[KidkArolis]

+1 On Jul 9, 2014 4:55 PM, "John Hann" notifications@github.com wrote:

Ah, if I remove moduleType altogether, I see what you are seeing. Here's what's happening:

1. rave's moduleType auto-detect mechanism only detects "amd", atm.
2. If it doesn't find an AMD code signature, it defaults to "globals".
3. Once it has determined that main.js is global, it looks in bower.json for dependencies and finds rave.
4. Since the rave/rave module isn't cached (this is a bug), it fetches it again, but this time the es6 loader code doesn't correctly detect that it's running inside a browser for some reason.

Seems we should nip this in the bud (number 1 in the list, above). Perhaps we should attempt to sniff for CommonJS-formatted modules? I was initially against it, but now I think it makes sense as a secondary mechanism. The primary mechanisms are a) explicit moduleType, b) npm heuristic that implies moduleType = ["node"].

Unless anybody objects, I'll add CommonJS sniffing asap.

— Reply to this email directly or view it on GitHub https://github.com/RaveJS/rave/issues/31#issuecomment-48494396.

[unscriptable]

I just pushed support for auto-sniffing CommonJS and it seems to work in my tests.