Skip to content

don't require explicit file extension #1

Open
michaelficarra opened this Issue Mar 3, 2013 · 12 comments
@michaelficarra

When it resolves, you should have the file extension.

@jakubmal
jakubmal commented Mar 3, 2013

Kind of doesn't make sense to me, why would you want to do that?

Btw I don't know any method of discovering the language used in a file except for maybe "try to parse and check for errors". Could you post a link to any project which has this implemented? If it makes sense, I would do the pull request.

@jakubmal
jakubmal commented Mar 3, 2013

Oh, I probably understand now, you mean that it requires to have an extension in path in require(path)
I will take a look at it, although it seems to be more on the side of browserify

@jhchen
jhchen commented Mar 22, 2013

I'm having the same issue and found a workaround. coffeeify depends on browserify which depends on browser-resolve which depends on resolve. resolve is equipped to look for multiple extensions but browser-resolve does not take advantage of this. So the workaround is to add this option in browser-resolve/index.js:

@@ -133,7 +133,8 @@
             var replace_main = info.browser[info.main || './index.js'];
             info.main = replace_main || info.main;
             return info;
-        }
+        },
+        extensions: ['.js', '.coffee']
     }, function(err, full) {
         var resolved = (shims) ? shims[full] || full : full;
         cb(null, resolved);

I'm not sure here is the best way fix this issue but conveniently @substack owns all of these repositories so he might know better.

@jiyinyiyong

Same here. Hope there's require('./name') for both .js .coffee files.


Update:
With that feature, I then may just compile .coffee file into a valid NPM package.

@dignifiedquire

:+1: from me. It's really ugly to have all these .coffees lying everywhere around.

@mahnunchik

+1

@staryj
staryj commented Apr 24, 2013

+1

@mahnunchik mahnunchik referenced this issue in defunctzombie/node-browser-resolve May 2, 2013
Closed

don't require explicit file extension #19

@andreypopp

related to defunctzombie/node-browser-resolve#12 which is, unfortunately, closed without explanation

@jackcviers

I'd love this feature myself. @jhchen Can you put a PR on browser-resolve with your workaround?

@andreypopp

@jackcviers see defunctzombie/node-browser-resolve#12 and related PRs to module-deps and browserify

@techpines

+1 This sucks, and it's keeping us at browserify 1.x

@ELLIOTTCABLE

+1.

When project meta-tooling requires you to change your source-code, then it's bad tooling.

(Side-note: The required change, at the moment, is in other libraries, and seems to mostly depend on @shtylman; as @substack has already agreed to merge the required changes into browserify.)

@ELLIOTTCABLE ELLIOTTCABLE added a commit to ELLIOTTCABLE/Paws.js that referenced this issue May 24, 2013
@ELLIOTTCABLE ELLIOTTCABLE (new meta) Coverage tooling! (And a shit-ton of other stuff.)
This is a fucking mess, too. In so many ways, not controllable by myself. Where to start ...

The `require()` problem™
========================
 - coffeeify (for browserify 2.x) *requires* that every `require()` statement explicitly end with
   the string ".coffee", to grab the file and bundle it into the browserify bundle
 - after instrumenting for coverage, the relevant (*instrumented*) files are `.js` files; thus, all
   of my `require('fuck-me.coffee')` statements will fail within the instrumented code; not to
   mention that the tests themselves also have to directly require the `.coffee` files
 - browserify will only work with `require()` statements for which the first argument is a direct
   string-literal in the source-code; so we can't work around this with the obvious
   complex-expression *in-place*

So, until the whole clusterfuck that is substack/coffeeify#1 is fixed (see also:
defunctzombie/node-browser-resolve#19, defunctzombie/node-browser-resolve#20), I've created a shim-file that
*wraps* the local `require` for each file in another function which mangles the name as necessary
based on the coverage environment variables, and then *replace* the local `require` function
in-scope with that wrapper.

Thus (phew), we can:

1. Satisfy browserify 2.x with ASTs of the exact form `require('<string literal>')` (hey, *it*
   doesn't know that the *value* of the `require` token has been re-defined!)
2. Satisfy coffeeify with string-literals ending in `.coffee`
3. Generate coverage for instrumented plain-JavaScript files that actually *resolve* all of their
   requires

Fuck Cake
=========
What the title says.

Node is great for a lot of things, but “rake”-style task management isn't one of them. I briefly
considered simply using Rake, even though I'm in a JavaScript project ... but then I decided to go
with the Node-y UNIX flow, and just resort to shell scripts. I'll be writing them generically (to
function in everything from dash, to bash, up to zsh); the remainder of migration from `Cakefile` to
`Scripts/*.sh` will happen in later commits. For now, though, I completely failed to reasonably
employ the available coverage tools through Node's `child_process` and similar, got fed up, and
immediately implemented both the `npm run-script coverage` and `npm run-script coveralls` as
shell-scripts, and just called out to *those* from the existing Cakefile.

Due to me being lazy in that way, we might have a hybrid Cake and shell-script build system for a
short while. Meh.

Travis-CI and Coveralls.io
==========================
There isn't any *official* support for Node (or JavaScript at all, for that matter) from Coveralls;
there's a third-party library, node-coveralls, but it's absolutely terrible. I've patched it and
pull-requested (see: nickmerwin/node-coveralls#6) to make it reasonably usable for my purposes here;
I've also had to modify some Travis configuration to work with all this. We'll see if it works when
I push this commit.
75fb580
@ELLIOTTCABLE ELLIOTTCABLE added a commit to ELLIOTTCABLE/Paws.js that referenced this issue May 24, 2013
@ELLIOTTCABLE ELLIOTTCABLE (new meta) Coverage tooling! (And a shit-ton of other stuff.)
This is a fucking mess, too. In so many ways, not controllable by myself. Where to start ...

The `require()` problem™
========================
 - coffeeify (for browserify 2.x) *requires* that every `require()` statement explicitly end with
   the string ".coffee", to grab the file and bundle it into the browserify bundle
 - after instrumenting for coverage, the relevant (*instrumented*) files are `.js` files; thus, all
   of my `require('fuck-me.coffee')` statements will fail within the instrumented code; not to
   mention that the tests themselves also have to directly require the `.coffee` files
 - browserify will only work with `require()` statements for which the first argument is a direct
   string-literal in the source-code; so we can't work around this with the obvious
   complex-expression *in-place*

So, until the whole clusterfuck that is substack/coffeeify#1 is fixed (see also:
defunctzombie/node-browser-resolve#19, defunctzombie/node-browser-resolve#20), I've created a shim-file that
*wraps* the local `require` for each file in another function which mangles the name as necessary
based on the coverage environment variables, and then *replace* the local `require` function
in-scope with that wrapper.

Thus (phew), we can:

1. Satisfy browserify 2.x with ASTs of the exact form `require('<string literal>')` (hey, *it*
   doesn't know that the *value* of the `require` token has been re-defined!)
2. Satisfy coffeeify with string-literals ending in `.coffee`
3. Generate coverage for instrumented plain-JavaScript files that actually *resolve* all of their
   requires

Fuck Cake
=========
What the title says.

Node is great for a lot of things, but “rake”-style task management isn't one of them. I briefly
considered simply using Rake, even though I'm in a JavaScript project ... but then I decided to go
with the Node-y UNIX flow, and just resort to shell scripts. I'll be writing them generically (to
function in everything from dash, to bash, up to zsh); the remainder of migration from `Cakefile` to
`Scripts/*.sh` will happen in later commits. For now, though, I completely failed to reasonably
employ the available coverage tools through Node's `child_process` and similar, got fed up, and
immediately implemented both the `npm run-script coverage` and `npm run-script coveralls` as
shell-scripts, and just called out to *those* from the existing Cakefile.

Due to me being lazy in that way, we might have a hybrid Cake and shell-script build system for a
short while. Meh.

Travis-CI and Coveralls.io
==========================
There isn't any *official* support for Node (or JavaScript at all, for that matter) from Coveralls;
there's a third-party library, node-coveralls, but it's absolutely terrible. I've patched it and
pull-requested (see: nickmerwin/node-coveralls#6) to make it reasonably usable for my purposes here;
I've also had to modify some Travis configuration to work with all this. We'll see if it works when
I push this commit.
84c75de
@mjpizz mjpizz referenced this issue in jnordberg/coffeeify Jun 7, 2013
Closed

Automatically add .coffee/.litcoffee extensions #1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.