0.7 FFI interaction with non-purescript bower dependencies

[purescript-contrib]

0.7 FFI interaction with non-purescript bower dependencies

[bodil]

You're right, the current convention seems a bit risky. @paf31?

[paf31]

For this to cause problems, I think all of the following have to hold:

1. A module is called purescript-something in bower_components
2. That module has a .js file under src/
3. That JS files has a magic // module ... comment (otherwise the compiler won't accept it as an FFI module anyway, and you'll get an error early on in the compilation process)

I would say this would be rare enough to not worry, but I'm happy to discuss alternatives.

It might be a good idea for the compiler to warn and continue, instead of raising an error, when 3) holds though.

[garyb]

@paf31 re: 1, the glob doesn't mention purescript-, so that's probably the only problem here.

[paf31]

Oops, I see. Yes, that should definitely be there.

I'll send a PR.

[paf31]

We are, of course, trading one global convention for another here, but I think this one (dependencies being called purescript-something) is more likely to be used in practice.

[garyb]

Very true. I quite like the idea of .purs.js too, shame we didn't do that already in the core libraries.

[bodil]

I agree, .purs.js would be the cleanest solution here. Requiring PS packages to always be called purescript-something is a bit iffy, but it's probably a convention that's entirely valid right now, so let's go with it until it starts causing trouble.

[paf31]

I think the problem is that the compiler tries to be entirely conventionless, whereas pulp tries to do the exact opposite, so at some point, it's naturally going to run into the need for global conventions. Arguably it already has: the compiler doesn't enforce that PureScript source files be called *.purs, but it's a global convention which everyone has adopted.