browserify / browser-resolve

resolve function which support the browser field in package.json

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

don't require explicit file extension

mahnunchik opened this issue · comments

related to #12

Coffeescript files are not javascript. Extensions required.

Can we have a way to alter this behaviour? It would be very handy for browserify/browserify#336

Trying to require every file as if it was javascript is really not the point of these tools. Coffeescript is NOT javascript. Compile to languages do not make them the same as the "native" languages for that environment. Just use the extensions and be explicit about it, this already works.

"Node allows loading coffee modules via require.extensions registry."

@shtylman Some people (including me) treat CoffeeScript another way, I think, the number of opened issues related to these already speaks for that.

Trying to require every file as if it was javascript is really not the point of these tools

This can be the default behaviour but why not having an option to alter it? node-resolve already works that way so I don't really understand why not expose this in the node-browser-resolve API.

I realize some people treat it a different way, but this is the same as doing require('foo.py') and expecting it to work. I am not stopping you from using coffeescript, I am just telling you that I don't care :) If you make a pull request to do it I might consider it, but really, the whole idea of one tool does everything for every language is rather silly to me.

@shtylman I already did such PR #12 which you turned down without an explanation :-)

but really, the whole idea of one tool does everything for every language is rather silly to me.

I agree with you here but look, we still can have a single and integral idea, just widened a bit — from "mapping a module id to js source code" to "mapping a module id to source code" ;-)

"mapping a module id to source code" ;-) just makes your code that much harder to follow and figure out. When you switch languages, it should be clear.

@shtylman

"mapping a module id to source code" ;-) just makes your code that much harder to follow and figure out

this is very subjective opinion

When you switch languages, it should be clear.

Clear to whom? It probably shouldn't make any difference for consumers of an API if modules written with different language expose compatible API and even ABI (which is the case with CoffeeScript and JS). Unfortunately because of this issue it's not possible.

Specifying an extension in require() calls breaks abstraction.

@shtylman please also note, that this functionality also goes straight in line with the Browserify philosophy — "Write your browser code with node.js-style requires". Node.js allows to load code written in different from JS languages by using require.extensions registry. I think browserify should also allow that if it states it could be "Node.js require but for browsers".

I think browserify should also allow that if it states it could be "Node.js require but for browsers".

+1

require.extensions is deprecated. There is no reason why browserify should support it or respect.

Do things properly and load javascript. If you compile your coffeescript into valid javascript then you will have no issues.

@Raynos can you elaborate on require.extensions deprecation? I see require.registerExtension() is being deprecated but have no google results on deprecation of require.extensions and official docs has no statements regarding these.

@Raynos I see now nodejs/node-v0.x-archive@7bd8a5a
Ok, it is a reasonable argument now.

@andreypopp for modules you put on npm you really should transpile into javascript on pre publish.

For your browser applications in coffeescript. best bet is probably a two stage build thing where you go coffee -> javascript -> browserify That kind of sucks, I agree, however if its not a perf issue then its not a big deal.

@Raynos I totally agree about publishing only js to npm.

That kind of sucks, I agree

That sucks a lot — I have to write compiled code to filesystem first, this adds a lot of complexity to build processes.

+1. Just adding my voice here. I've already commented on substack/coffeeify#1, but … more noise can't be anything but helpful in getting this “solved,” I suppose.