Actually publish the browser compilers to NPM

[GeoffreyBooth]

Well, I just announced 2.4.0 with a fancy new ES module version of the browser compiler, but that new compiler didn’t get published to NPM because it’s not in the package.json files block. Oops.

It feels a little weird to publish a path into the docs folder, but it also feels wrong to have two copies of the browser compilers both checked into the repo. Thoughts? The version in docs needs to be there in order for the browser compiler to be used in the docs site.

I’m going to wait a few days before publishing 2.4.1, to see if anyone reports any (other) bugs in 2.4.0.

cc @jashkenas

[GeoffreyBooth]

Update: I put a copy of each browser compiler into the lib folder:

  "module": "./lib/coffeescript-browser-compiler-modern/coffeescript.js",
  "browser": "./lib/coffeescript-browser-compiler-legacy/coffeescript.js",

Is there a reason browser was previously "./lib/coffeescript/browser"?

And can someone please explain to me the lib folder? Am I wrong to add to it like the above?

cc @jashkenas @lydell

[lydell]

Sorry, I have no idea.

[jashkenas]

It feels a little weird to publish a path into the docs folder, but it also feels wrong to have two copies of the browser compilers both checked into the repo. Thoughts? The version in docs needs to be there in order for the browser compiler to be used in the docs site.

My immediate hunch to address this would be to get rid of the "docs" folder, and just start publishing the GitHub Page directly from master (or from gh-pages). Then index.html goes in the project root, docs contains the rest of the documentation files, and you can use whatever you like from lib.

As a separate note — it feels a little wrong to have both the regular Node module and the compiled browser compiler be part of the same npm module, since they're duplicative of each other, and for any given use, you only need one of them, not both ... but I guess it’s alright, as long as the browser compiler isn't too huge.

[GeoffreyBooth]

it feels a little wrong to have both the regular Node module and the compiled browser compiler be part of the same npm module

Agreed, but people use npm modules in differing ways these days, as you've seen with the PR about making this work with Webpack. It's becoming common for npm modules to support multiple targets (Node, build tools, ES modules, browsers, etc.) and file size of overall packages doesn't seem to be much of a concern.

Did you see my last comment above about lib? Can you please explain that folder, and let me know if my proposal there is good?

[jashkenas]

Did you see my last comment above about lib? Can you please explain that folder, and let me know if my proposal there is good?

Yes, but I don't really understand what you mean ... lib is the compiled JavaScript of the original CoffeeScript src. But I think I'm misunderstanding the true question.

[GeoffreyBooth]

Yes, but I don’t really understand what you mean … lib is the compiled JavaScript of the original CoffeeScript src. But I think I’m misunderstanding the true question.

Okay, so there’s no greater significance than that, it sounds like? I assume it’s fine for me to add additional subfolders under lib, so we would have e.g.:

• lib/coffeescript-browser-compiler-legacy/coffeescript.js
• lib/coffeescript-browser-compiler-modern/coffeescript.js
• lib/coffeescript/index.js (and other files, the Node module as it exists today)
• lib/coffeescript-node-es-module/index.js (and other files, the Node module in ES module form someday, when Node supports ES modules)

So basically our lib folder is similar to the dist folder that many projects that use Babel have. We might want to consider .gitignoreing lib, and publishing it to NPM but not keeping it in GitHub.