<commit_before># browserify-rails

This project is currently in maintenance mode. New contributors are more than welcome!

[![Gem Version](https://badge.fury.io/rb/browserify-rails.svg)](http://badge.fury.io/rb/browserify-rails) [![](https://img.shields.io/gem/dt/browserify-rails.svg)](https://rubygems.org/gems/browserify-rails)

This library adds CommonJS module support to Sprockets (via Browserify).

It lets you mix and match  `//= require` directives and `require()` calls for including plain javascript files as well as modules. However, it is important to remember that once you are into code that is being browserified you can no longer use sprockets-style require (so no `//= require`). In many cases, it makes sense to put all your sprockets-required code in a separate file or at the very least at the top of your main JavaScript file. Then use `require()` to pull in the CommonJS code.

1. Manage JS modules with `npm`
2. Serve assets with Sprockets
3. Require modules with `require()` (without separate `//= require` directives)
4. Only build required modules
5. Require *npm modules* in your Rails assets
6. Require modules relative to asset paths (ie app/assets/javascript) with non-relative syntax (see below before using)
7. Configure browserify options for each JavaScript file so you can mark modules with `--require`, `--external`, etc

## Should you use this gem?

As the primary developer, I'm going to offer some opiniated advice. The sweet spot for this
gem is for Rails projects with legacy JavaScript (not using CommonJS/modules). This gem is
a great way to make it possible to rewrite that legacy JavaScript to CommonJS on a timeline
that you dictate. Then consider stepping off the Rails asset pipeline or using another gem.

If you're starting a new Rails project today, I highly recommend looking at alternatives to
this gem. The primary reason is that this gem, while it works well, is not as efficient as
most would like for local development. Also a lot has changed over the last couple of years.

An example of that change is this project from Rails:

[rails/webpacker](https://github.com/rails/webpacker)

This is a huge step in the right direction for the Rails community. In the past, it has been
extremely frustrating working with JavaScript on the asset pipeline. The good news is you have a lot
of great choices. If I were starting a new Rails project today, I think the safest choice is
one in which you have a Procfile that kicks off a separate Webpack build and you use zero
Rails magic. A slightly less safe but maybe more convenient choice would be trying rails/webpacker
or another gem. The choice is yours.


For more discussion on this topic, see issues
[203](https://github.com/browserify-rails/browserify-rails/issues/203),
[161](https://github.com/browserify-rails/browserify-rails/issues/161),
[43](https://github.com/browserify-rails/browserify-rails/issues/43), etc.

## Getting Started

Add this line to your application's Gemfile:

    gem "browserify-rails"

Create `package.json` in your Rails root:

```js
{
  "name": "something",
  "dependencies" : {
    "browserify": "^14.0.0",
    "browserify-incremental": "^3.1.0"
  },
  "license": "MIT",
  "engines": {<commit_msg>minor tweak to README<commit_after># browserify-rails

This project is currently in maintenance mode. New contributors are more than welcome!

[![Gem Version](https://badge.fury.io/rb/browserify-rails.svg)](http://badge.fury.io/rb/browserify-rails) [![](https://img.shields.io/gem/dt/browserify-rails.svg)](https://rubygems.org/gems/browserify-rails)

This library adds CommonJS module support to Sprockets (via Browserify).

It lets you mix and match  `//= require` directives and `require()` calls for including plain javascript files as well as modules. However, it is important to remember that once you are into code that is being browserified you can no longer use sprockets-style require (so no `//= require`). In many cases, it makes sense to put all your sprockets-required code in a separate file or at the very least at the top of your main JavaScript file. Then use `require()` to pull in the CommonJS code.

1. Manage JS modules with `npm`
2. Serve assets with Sprockets
3. Require modules with `require()` (without separate `//= require` directives)
4. Only build required modules
5. Require *npm modules* in your Rails assets
6. Require modules relative to asset paths (ie app/assets/javascript) with non-relative syntax (see below before using)
7. Configure browserify options for each JavaScript file so you can mark modules with `--require`, `--external`, etc

## Should you use this gem?

As the primary developer, I'm going to offer some opiniated advice. The sweet spot for this
gem is for Rails projects with legacy JavaScript (not using CommonJS/modules). This gem is
a great way to make it possible to rewrite that legacy JavaScript to CommonJS on a timeline
that you dictate. Then consider stepping off the Rails asset pipeline or using another gem.

If you're starting a new Rails project today, I highly recommend looking at alternatives to
this gem. The primary reason is that this gem, while it works well, is not as efficient as
most would like for local development. Also a lot has changed over the last couple of years.

An example of that change is this project from Rails:

[rails/webpacker](https://github.com/rails/webpacker)

This is a huge step in the right direction for the Rails community. In the past, it has been
extremely frustrating working with JavaScript on the asset pipeline. The good news is you have a lot
of great choices. If I were starting a new Rails project today, I think the safest choice is
one in which you have a [Procfile](https://mattstauffer.co/blog/using-a-procfile-to-streamline-your-local-development) that kicks off a separate Webpack build and you use zero
Rails magic. A slightly less safe but maybe more convenient choice would be trying rails/webpacker
or another gem. The choice is yours.


For more discussion on this topic, see issues
[203](https://github.com/browserify-rails/browserify-rails/issues/203),
[161](https://github.com/browserify-rails/browserify-rails/issues/161),
[43](https://github.com/browserify-rails/browserify-rails/issues/43), etc.

## Getting Started

Add this line to your application's Gemfile:

    gem "browserify-rails"

Create `package.json` in your Rails root:

```js
{
  "name": "something",
  "dependencies" : {
    "browserify": "^14.0.0",
    "browserify-incremental": "^3.1.0"
  },
  "license": "MIT",
  "engines": {
{'fraction_non_alphanumeric': 0.0852394022567856, 'fraction_numerical': 0.009149130832570906, 'mean_word_length': 4.349918433931484, 'pattern_counts': {'":': 10, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 15, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3034157', 'n_tokens_mistral': 1888, 'n_tokens_neox': 1740, 'n_words': 883}