jnordberg / coffeeify Goto Github PK

As mentioned by @startswithaj in browserify issues, v7.0.0 breaks coffeeify when used with watchify. @startswithaj has well explain the problem: browserify/browserify#1012

Copy of the original issue:

The transform changes introduced in 7.0.0 cause coffee-script compiles to be called on already compiled data when bundle() is called after the initial bundle.

b = browserify
  extensions: ".coffee"
  debug: true
  cache: {}

bundler = watchify b
bundler.transform coffeeify
bundler.add paths.entry
bundler.on 'update', =>
  bundler.source = null
  bundler.bundle (err, src) =>
      bundler.source = src
      reloadJS(clients)

bundler.on 'log', (msg) => 
  console.log msg

# Start browserifying script resources
bundleStream = bundler.bundle (err, src) ->
  if err then console.error "initial browserify bundling error: \n  %s \n  %s %s:%s", err.toString(), err.file, err.location?.first_line, err.location?.first_column, terminalAlertBadge
  bundler.source = src

See data property in scope variables

When using with coffee-script 1.11.0 or 1.11.1 (latest at the time of reporting) this command:

browserify --debug --transform coffeeify --extension .coffee --outfile build/application.js src/index.coffee

produces a bundle with source maps that make Chrome Dev Tools display files with .coffee extensions, but compiled JS content, whit source maps string at the bottom:

It might be related to change in lexer and parser announced in the changelog for v. 1.11.0:

Improved the internal representation of a CoffeeScript program. This is only noticeable to tools that use CoffeeScript.tokens or CoffeeScript.nodes. Such tools need to update to take account for changed or added tokens and nodes.

I don't think it's a bug in CS, as the source maps are generated correctly if I do it like that:

coffee -cMo build/js/ src/
browserify --debug --outfile build/application.js build/js/index.js

As a side node, why do we force a coffeescript version in this package ?
We could let it to the developer discretion, shouldn't we ?

The sourcemaps generated by coffeeify have an absolute path to the original .coffee file, which breaks source loading.

I've made a sample app demonstrating the problem. After checking out:

npm install
npm run bundle

... open index.html in a browser, and look at the javascript sources. Chrome actually will follow the absolute path to bar.coffee, but Firefox will fail to load the source.

The (base64 decoded) sources portion of the sourcemap looks like:

"sources":[
  "../../../../usr/local/lib/node_modules/browserify/node_modules/browser-pack/_prelude.js",
  "app.js",
  "/Users/kingp/Projects/coffeeify_bug_submission/bar.coffee",
  "foo.js"
],

Manually changing the absolute path to just bar.coffee fixes the problem.

Problem: coffeeify causes browserify to generate a SyntaxError when the input file contains global keyword.

To recreate:

$ npm install -g browserify # installs 3.24.11
$ npm install coffeeify # installs 0.6.0
$ echo "console.log(global)" > test.coffee
$ browserify -t coffeeify test.coffee > test.js
SyntaxError: Line 3: Unexpected end of input while parsing /Users/jamesgary/huh/test.coffee

The fact that it detect SyntaxError on line 3 of a one-line file leads me to believe coffeeify/browserify is expanding global prematurely.

global works fine when browserifying .js files, but not .coffee files, which leads me to believe it is an error in coffeeify. Let me know if this issue belongs in node-browserify instead.

Possibly related: browserify/browserify#616

I tried this module hack https://github.com/substack/browserify-handbook#avoiding-

app/
  - foo.coffee
  - initialize.coffee
node_modules/
  app -> ../app # alias to app

require('app/foo') in initialize.coffee doesn't work. (maybe it is handled as pure javascript)

Is this in coffeeify role?

When I have a coffee file with escaped JSX code in it

###
  @jsx React.DOM
###

Dropdown = React.createClass
  render: ->
    @transferPropsTo `
      <div class="btn-group">
        <button tabIndex='-1' type='button' class="btn dropdown-toggle"
            data-toggle="dropdown">
          <span class="caret"></span>
        </button>
        <ul class="dropdown-menu">
          {this.props.children}
        </ul>
      </div>`

And I use this grunt task:

    browserify:
      'build/app.js': ['clientapp/dropdown.coffee']
      options:
        transform: ['coffeeify']

I get:

$ grunt browserify
Running "browserify:build/app.js" (browserify) task
Warning: Unexpected token < Use --force to continue.

Aborted due to warnings.

It seems like the backtick escape isn't being acknowledged in the coffeeify transform.

When I have a syntax error I just see undefined in my browser window. The terminal that the beefy server is running in shows nothing. Where do I see syntax errors, etc.? I'm sorry if this is a stupid question.

My command (as the terminal shows it when a request is served) ...

./node_modules/browserify client/app.coffee -d -o bundle.js -t coffeeify --extension .coffee

This works fine:
browserify -t coffeeify/no-debug blah.coffee > bundle.js

This does not:
browserify -t coffeeify blah.coffee > bundle.js

blah.coffee:3
//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiL2hvbWUvbWF0dC9zcmMvbGZtL3B1YmxpYy92aWV3cy9ibGFoLmNvZmZlZSIsInNvdXJjZVJvb3QiOiIiLCJzb3VyY2VzIjpbIi9ob21lL21hdHQvc3JjL2xmbS9wdWJsaWMvdmlld3MvYmxhaC5jb2ZmZWUiXSwibmFtZXMiOltdLCJtYXBwaW5ncyI6IkFBQUEsT0FBTyxDQUFDLEdBQVIsQ0FBWSxvQkFBWixDQUFBLENBQUEiLCJzb3VyY2VzQ29udGVudCI6WyJjb25zb2xlLmxvZyBcInRoaXMgaXMgYSB0ZXN0IDEyM1wiIl19
^^
ParseError: unexpected //

Currently compiler crashes because it can't compile JSX without this flag. When calling coffeescript programmatically it expects a babelrc configuration object. Why not simply allow to pass it through? Or pass through all unknown compiler options for future compatibility?

Something like this: https://github.com/jnordberg/coffeeify/pull/44/files

After upgrading from version 1.2.0 to any version 2.0.0-2.0.1, in an otherwise unchanged environment, I can no longer see the CoffeeScript source in Chrome's debugger.

This is with [email protected], loaded as a dependency of [email protected] (which is the latest at the time of writing).

Transforms are configured in package.json:

  ...
  "browserify": {
    "transform": [
      "coffeeify",
      "hbsfy",
      "browserify-shim"
    ]
  },
  ...

Options passed into browserify from grunt-browserify:

  "detectGlobals": true,
  "extensions": [
    ".coffee",
    ".hbs"
  ],
  "noParse": [
    "jquery"
  ],
  "debug": true

Note that the debug flag is enabled.

However, best as I can tell, the options argument to coffeeify( ... ){ ... } is always an empty object. Excerpt from: index.js:

...
function coffeeify(filename, options) {
    if (!isCoffee(filename)) return through();

    if (typeof options === 'undefined' || options === null) options = {};

    var compileOptions = {
        sourceMap: (options._flags && options._flags.debug),
        bare: true,
        header: false
    };
    ...

Minimum reproduction here:
https://github.com/jamestalmage/coffeeify-issue

Is is possible to save the transformed coffee sources as js files so they can be required in node?
I'm using coffeeify with grunt and it works perfect for generating my client bundle and it would be great if I didn't have to use something else for generating the js files again.

Hey man,

since I am using coffeeify and browserify in the command line, I simply cant pass any options to coffeeify.

Is it possible for us to add a feature to read configurations to disable sourceMaps in the package.json file? This feature exists here https://github.com/domenic/jadeify

What do you think about it?

I actually need to disable sourceMaps since I am not being able to use it properly, I believe I created some issues around it, but I just gave up trying.

Hi,

I have this Javascript library that I'm authoring: https://github.com/wilkerlucio/composed-validations

I have a browser compilation script there for browser versions, that works just fine: https://github.com/wilkerlucio/composed-validations/blob/master/scripts/build

So, browserify + coffeeify is able to compile that. But when I try to do the same externally it does a parsing error...

How to reproduce the problem:

mkdir example-app
cd example-app
npm init
npm install -S composed-validations
npm install -D browserify coffeeify
echo "require('composed-validations')" > browser.js
./node_modules/.bin/browserify -t coffeeify browser.js

And you will get something like:

Error: Parsing file /Users/wilkerlucio/Development/coffeeify-bug/node_modules/composed-validations/lib/index.coffee: Line 2: Unexpected token :

I tried to debug it, and it seems that for some reason the coffeify transformer is not even being called on the module files... I'm not sure if this is a Browserify bug or Coffeeify bug...

Do you guys have any ideas about what's going on?

I made a repro repo here: https://github.com/ianthehenry/symlink-bug

The crux of this is that you can't use symlinks to namespace directories, but symlinks to files work as expected.

Right now only the CLI is documented. This means anyone who is unfortunate enough to have to use the API will need to reverse engineer it.

Hey guys,

here, I am using browserify with coffeeify and browserify-shim as the transforms. I am guessing that the usage of browserify-shim is affecting the sourceMaps.

What can I do about it? What do u guys are doing regarding this issue, since I cant believe that everybody bundles jquery and other libraries into their bundle.

Thanks!

Hey guys,

I have a main.coffee which has "require('helpers')" in it, and I thought it would be easy for enchilada with coffeeify to automatically find helpers.coffee .

I'm doing:

enchilada_ify = enchilada
  src: rootPath
  extensions: ['.coffee']
  routes:
    '/js/main.js': rootPath + '/js/main.coffee'
  transforms: [ coffeeify ]
app.use enchilada_ify

And rendering /js/main.js gives:

Error: module "helpers" not found from "/vagrant/public/js/main.coffee" at notFound ...

Any advice?

See #6

Patches welcome

... or figure out how to best share code between the modules.

Moving this out from the discussion in #1.

Personally i'm in favor of merging the 2 modules since the overhead from the caching is very small (md5(source) for each file) and i think most users would benefit from it. Perhaps adding a setting to allow you to disable it in applications where first-run performance really matters.

@mjpizz had an interesting solution to the problem by only enabling caching on the second run but i'm wary of adding functionality that tries to be too "smart". I can easily see a developer pulling his hair out trying to understand why stuff only goes wrong after the second or third request

Now that i think more on this, wouldn't the best solution be to have a generic cache module? something the through module but with caching support that replays a stream if the input stream is the same.

...anyways, what i'm looking for is a way to keep the 2 modules in sync :) Right now they behave differently

According to the browserify documentation, when you require a module/folder, it looks for an index.js file.
Would it be possible with coffeeify to tell browserify to look for index.coffee instead ?

How can I use your plugin with Gulp?

I was debugging an issue using coffeeify internally deepak1556/gulp-browserify#7.

I slimmed the problem down into the following principle code that doesn't work:

var file_stream = fs.createReadStream('./coffee/subdir/a.coffee')

var opts = {}
opts.basedir = __dirname + '/coffee/subdir'

browserify(file_stream,  opts)
    .transform('coffeeify')
    .bundle()
        .on('error', console.log)
    .pipe(process.stdout);

What happens is that since the stream input has lost its file information, a tmp file is created via browserify in these following lines: https://github.com/substack/module-deps/blob/master/index.js#L23

module-deps is what browserify uses for processing. The tmp file created happens to be in .js extension -- and fails the isCoffee test within coffeeify, thereby making coffeeify act like a passthrough stream (stream contents passively passing to the next stream).

I propose a change in isCoffee and isLiterate methods to somehow lint the contents of file (the path) passed to coffeeify.