Add package.json with private set to true

[dmfrancisco]

At the company I work for we've been using Cocoon for more than 2 years now. Thanks @nathanvda and everyone that contributed! 👏

We recently migrated to Rails 5.1 and stopped using the Asset Pipeline to compile our JavaScript (we're using the Rails Webpacker gem). This means we can't require JavaScript like this anymore:

//= require cocoon

I've read issues #363 and #452 and understand if the author is not interested in maintaining another package in a different registry (NPM). What I propose in this PR is a compromise solution.

This PR adds a package.json file with the property private set to true. This lets users that visit this repository know that the JavaScript is not officially published in the NPM registry, but at the same time they can install Cocoon directly from GitHub:

# Using the NPM client
npm install github:nathanvda/cocoon --save

# Using the Yarn client
yarn add github:nathanvda/cocoon

They can then import the code like this:

import "cocoon";

The package.json includes a version because it is a required property, but even if this property is not updated, users can always install a specific commit, similarly to what we do in a Gemfile:

npm install github:nathanvda/cocoon#c24ba53

---

Side note: If in the future @nathanvda finds it valuable to publish the package in the NPM registry, he would simply have to remove the private property, update the version, and run npm publish.

Both names "cocoon" and "cocoon-rails" are taken, but the author can use a scoped name. Assuming the NPM username nathanvda, the name property could be @nathanvda/cocoon.

[nathanvda]

Thank you, this seems pretty awesome.

I still did not make the switch to using webpacker/yarn/npm and now I am a bit irritated because I will have to check that all out sooner 😛 😛 Nooooo just joking 👍 you are giving me a great incentive to dive a little deeper, but I will not merge until I fully understand it.

This does sound like the ideal solution for now.

[revgum]

@nathanvda Any traction on this yet? This PR would be awfully nice versus the current workarounds (ie. copying cocoon.js directly into app/javascript/packs and having it compile)

[johnnyshields]

@nathanvda please take a moment to add this JS to NPM. It's not difficult to do.

[pedrofurtado]

@nathanvda It is a great time to merge it 👍 🎉

[robert-sjoblom]

@nathanvda we forked your repo today to use this solution; if we submit a fixed PR, will you use that? I ask because while the solution works locally, we'd like to help out with open source projects and we'll probably use this gem in other projects, but if there's no interest in our PR we won't spend any time correcting issues.

[kirillplatonov]

@nathanvda thanks a lot for this amazing library. I just forked it as well to add package.json and have the ability to use it with webpacker. Nowadays more and more rails apps transitioning from sprockets to webpacker so it would be great to have package.json file for this library. It won't add or change any functionality but will allow using the library with both sprockets and webpacker.

[ahlucas]

what's the state of this?

[pedrofurtado]

@nathanvda 👍

[jrochkind]

Rails 6 will not by default support sprockets asset pipeline for JS (although there may be a way to hack it in).

I don't wanna stop using cocoon! I also don't wanna be forced to hack the sprockets asset pipeline for JS back in.

Would love a solution, any chance of progress on this?

[pedrofurtado]

@jrochkind @WillRadi @marciojesus For anyone that wants to use cocoon with package.json, you could add this in your package.json (company where I work is using this approach until the PR is merged):

{
  "dependencies": {
    "cocoon": "https://github.com/pedrofurtado/cocoon#master"
  }
}

and, then, in your JS files, import like this:

import $ from 'jquery'
import jQuery from 'jquery'
import { cocoonInitializer } from 'cocoon/app/assets/javascripts/cocoon'

// to initialize cocoon ...
cocoonInitializer($, jQuery)

// to catch events from cocoon ...
$(document).on('cocoon:after-insert', () => {
    // ...
})

My company and me will maintain the fork ( https://github.com/pedrofurtado/cocoon ) synced and updated until the PR get merged 👍

[sikandartariq1]

any update on this? GitHub package registry can be used now too.

[jrochkind]

Do you see the GH package registry making things easier or simpler, @sikandartariq1 ? I don't understand it much (or ordinary npm registry really), and am curious what you see it's use being.

(I am not a cocoon maintainer/committer, just another user).

[sikandartariq1]

@jrochkind just won't have to leave the GitHub platform to create a package which makes things a bit familiar (I would say) for developers (like us from rails background) not very used to with npm and staff. Other than that nothing special or easier I guess

[jrochkind]

OK thanks, I'm new to this stuff and looking into it, but I think you still need to use the npm command line to do a release, after telling it to publish to github package manager. It might still overall be simpler, I guess you don't need an npm repo account. Not sure, I'm new to npm package relasing too, trying to figure out the simplest way to do things.

Not a maintainer/committer of cocoon -- but yeah, I think that if cocoon doens't release itself as an npm package soon, it's going to be considered unmaintained/incompatible with Rails6, as an npm package is what's needed for Rails6.

It is fairly straightforward to take the existing code and release as an npm package; the thing I haven't quite figured out yet is how to organize source/workflow to allow use both with sprockets and the JS in rubygems source and an npm package. The alternative would be cutting a new release that only supported npm/webpacker use I guess.

I am getting the feeling that cocoon's maintainer(s) are not themselves using Rails6/webpacker though, so don't have much motivation for this. It's not clear to me how maintained cocoon currently is.

[pedrofurtado]

@nathanvda 👍

[alejandrodevs]

I think this can work:
#555 (comment)

[nathanvda]

@jrochkind yes, for the moment my rails applications have still not migrated to rails 6, and in rails 5 I use the asset pipeline in combination with webpacker (which is still possible). I am also looking at a way how I can easily publish the gem and npm package in sync (aside from the fact that all interesting names for npm packages have been allocated with outdated js code).

I also have to rewrite js slightly to be able to publish to npm, but that is minor imho.

But I will have to find some time to support rails 6 correctly. I understand there are various work-arounds so it is not too pressing?

[robert-sjoblom]

@nathanvda github actions can publish both npm packages and gems; that's certainly one way to do it

[daviscabral]

Hey everyone!

I have been using this awesome project for the last couple of years and I would like to contribute on this to have this shipped.

What do we need to get this out?

@nathanvda what are your main concerns and how can I help to make you feel confident about this?

@pedrofurtado is there any more changes needed to be done here since this PR has been stale for a while?

EDIT:

My company and me will maintain the fork ( https://github.com/pedrofurtado/cocoon ) synced and updated until the PR get merged 👍

My bad for not noticing this.

Thank you everyone for the great job here.

[dfreerksen]

I am using cocoon for a Rails 6 and Webpack project and most everything works as expected. I have having a problem getting callbacks to run. I can across cocoon-vanilla-js which seems to work well for me https://github.com/kollegorna/cocoon-vanilla-js

yarn add @kollegorna/cocoon-vanilla-js

In my pack file I require it with

require('@kollegorna/cocoon-vanilla-js')

[hilarysk]

@pedrofurtado Are you not maintaining your fork anymore? Re: https://github.com/pedrofurtado/cocoon

[pedrofurtado]

@hilarysk No, we use a fork in "vanilla js version" for cocoon javascript behavior: https://github.com/pedrofurtado/cocoon-vanilla-js

is a fork of https://github.com/kollegorna/cocoon-vanilla-js 👍

With this change, we could drop jQuery as a dependency, use the gem cocoon for "ruby part", and for "javascript part" we use this repo above 🤝

[jrochkind]

It's really unclear to me what Rails 7.0.0 means for wanting to use cocoon, what the options are. Webpacker is out... but so is sprockets? Any advice welcome. And any orientation as to what's going to happen to this PR?

[kirillplatonov]

@jrochkind with Rails 7 it makes more sense to use Stimulus to handle nested forms. For example: https://stimulus-components.netlify.app/docs/stimulus-rails-nested-form/

[nathanvda]

@jrochkind I am going to check out and see how it works best in rails 7, hopefully this weekend/next week. I think rails 7 is a really interesting development. I keep this PR open, because there are so many awesome references to alternative js implementations, and I need to something about that (make page to list them maybe?). However in the README you can see my proposed solution when using webpacker (but of course, since the js and ruby code are now possibly completely separate there is nothing stopping to use the js library of your choice --e.g. without jquery dependency)

@kirillplatonov very interesting. I see a future in a combined cocoon/stimulus approach here. Nice!

[jrochkind]

@nathanvda Ah, I didn't see/realize you had released an npm package and listed it in the README, thank you!

The non-JQuery alternatives are interesting. Would you consider taking a non-JQuery alternative into cocoon proper, perhaps replacing the jQuery one?

The existing ones are of course a bit confusing ot figure out maintenance status and such. @pedrofurtado, can you explain why you forked kollegorna/cocoon-vanilla-js, what did you add to it? Because meanwhile the original at oddcamp/cocoon-vanilla-js seems to have a commit that you don't have, to implement a cocoon compat feature that had previously been "TODO". Did you consider sending your changes back to the original instead of forking?

I'd love to use a non-jquery version, but would feel more comfortable if there were at least a single one the community settled on instead of multiple forks, to have a better chance of it being maintained etc -- obviously even better if cocoon itself blesses or adopts it!