Seeking help

[aesopwolf]

This project is looking for new maintainers. You can show your interest by opening a PR that fixes something. To begin with I'll add pretty much anyone that opens a PR as a member, giving them the ability to merge their own PR (please be responsible). I'll also give you access to publish it to npm (again, please be responsible).

The community has shown a lot of interest in this project and when I first got involved I had good intentions to bring it back to life, but I haven't given this the time and love it deserves. So, hopefully, by converting this to a github org it will finally get the attention it needs.

[MilosRasic]

@aesopwolf My team, working on Gogo's B2B portal, has ran into formsy's lack of maintenance as a block on the road to React 16. We'd very much like to help with maintaining the project and getting it up to date, but due to the state of the repo I'd say some consensus is needed on how to proceed so that we don't end up doing work that is going to be rejected or reverted at a later date. Here's my rough idea:

1. Create a "mixins" branch from master to retain mixin support for anyone who may possibly still need it.
2. Merge beta into master
3. Update master to work with both React 15 and 16 and move React and ReactDOM to peerDependencies
4. profit??

Please let me know if this sounds ok or if you have a better idea and we'll get someone to work on it.

[apuntovanini]

@MilosRasic that sounds a good timeline, just a thought on the first point: since mixins are deprecated anyways, do we really need it? Completely agree from 2nd onwards 👍 , been using beta for weeks and works perfectly (not in react 16)

[MilosRasic]

@apuntovanini I don't know about the mixins branch. Does it hurt to have it? Why is there a react 14 branch for that matter? I'd keep them more because that seems to be how it was done before than for any other reason.

[apuntovanini]

Nope, it definitely doesn't hurt 😄 was just a thought, in case you need a help, happy to lend a hand or two

[rkuykendall]

Aside from getting good code that's already been written into the main branch and released ( Things like the 1.0 branch, the -2 fork, etc. ) I think we should prioritize the most popular non-api-breaking changes: https://github.com/christianalfoni/formsy-react/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

1. Deprecation of React.createClass
2. Deprecation of React.PropTypes
3. Support React v16.0

Many of these have already been fixed several times in several branches/PRs so I think the hard part will be knowing what to merge.

[rkuykendall]

This removed two branches that were over two years old, validation-errors-improvement and react-0.14. They are still in the original repo and I can bring them back if anyone objects. I also created a PR for the beta branch. @MilosRasic @apuntovanini it sounds like you both agree getting that branch merge-ready should be first priority?

[MilosRasic]

Absolutely. Time permitting, I'll try to get a React 16 fork working and test it in our thing that makes a pretty heavy use of formsy. If it works there it should work anywhere.

It would be nice if we could also get the readme straight. For example, in 1.0.0, withFormsy is exported as Wrapper.

[rkuykendall]

Trying to gather that information on PR, let me know if you have anything else: #3

I'll be getting more familiar with the 1.0 branch today, seeing what the upgrade process is in our own app ( also very heavy use of Formsy ).

[aesopwolf]

@MilosRasic that sounds like a great plan, and I agree with @apuntovanini that mixins aren't really needed. They could (should?) be left out for the 1.0 release. I'll add you to this repo and you can setup a roadmap using the gihub project feature. It would be nice to have an outline / roadmap that anyone is free to start picking up issues and opening PR's.

[rkuykendall]

After the most recent value prop-type PR was merged, everything seems to be working well on my upgrade branch. Does anyone have any testing they can do on their codebases, or additional must-have features for the first release?

The react 16 PR #11 is our only open PR as-is. I'm having trouble getting it running locally but I think that's my fault.

[MilosRasic]

I'll test on my work project after the weekend.

I'm thinking about publishing 1.0.1 as latest release as a React 15 release without React.PropTypes and create-class, then doing a 1.1.0 release at a later date that supports React 16.

Any issues or objections?

[apuntovanini]

@rkuykendall which issues are you facing? May I help you? @MilosRasic good idea about the releases. If you guys agree I think we should get a proper CHANGELOG.md running. I can take care of it, how about conventional-commits (https://conventionalcommits.org/)

[rkuykendall]

publishing 1.0.1 as latest release

And skipping 1.0.0? I think that the 1.0.0 version number properly communicates the upgrade-if-brave nature of such a significant code change.

I agree with getting a release out ASAP, since PropTypes and create class are older issues than 16 support. Though 16 support should be our next release goal.

which issues are you facing? May I help you?

My local was saying react-formsy didn't have react. I don't think it was your code, I think I may have just missed a step or I've done yarn build and yarn add file:./react-formsy too many times or something. How have you been setting up your dev react-formsy with your app?

Proper changelog additions would be great. There are some good notes in the 1.0 beta commit messages, some of which I copied to the 1.0 PR. We should make sure the breaking API changes and upgrade path are clear.

[apuntovanini]

@rkuykendall nope, didn't do anything special, just run yarn, and then yarn test, or yarn examples
I added CHANGELOG in #15, but I'd need some help for migration guide (I think it should stay in Changelog itself.
I really think #2 and #6 are already fixed in master branch (they where fixed in the previous beta branch on @christianalfoni repo), so we should just test it with React 16 and release it as a 1.0.0.
Then we can move to other things, what do you guys think?

[MilosRasic]

I think 1.0.0 is already released. Check the output of npm view formsy-react. Not 100% sure but I think it corresponds to the beta branch of the old repo, but not to latest on npm (npm install formsy-react@latest won't install it). That's why I suggested 1.0.1 but if I'm wrong and 1.0.0 is free on npm that's of course preferable version.

[apuntovanini]

@MilosRasic I think you're right, it is already released, but if that is true #2 and #6 are also already released. I think we can release 1.0.1 with #14 and move to a 1.1.0 for react 16 support as of #11 (or #15)

[apuntovanini]

One more thing: version 1.0.0 seems released, but has no lib folder in the npm package (plus on npm I still see 0.19.5 https://www.npmjs.com/package/formsy-react)

[rkuykendall]

Plus, the docs are clearly pre-1.0.0 beta branch. So either it's using an old one like @latest, or that 1.0.0 release is older than the beta branch. Either way, I wouldn't call that a real release, but I see no problem with going to 1.0.1 if there is a broken release in the way.

[apuntovanini]

Indeed, you're right, let's release 1.0.1 with updated docs from our master branch

[MilosRasic]

@aesopwolf could you please publish a 1.0.1 from master and/or give me npm permissions on https://www.npmjs.com/~mrasic ?

[rkuykendall]

https://www.npmjs.com/package/formsy-react 🎉

We did it!

[MilosRasic]

Renaming Wrapper (back?) to withFormsy broke formsy-react-components@next. Should we follow the React tradition and export both, with deprecation notice if Wrapper is imported?

[rkuykendall]

@MilosRasic That sounds nice, but also, it's a 1.x.x release, so breaking changes should be expected? Then again, this whole 1.0.0 vs 1.0.1 release situation is weird. I don't see a downside to keeping a depreciation notice around for a few minor revisions, to make the upgrade path easier.

[aesopwolf]

@MilosRasic I just gave you permissions on npm :)

[rkuykendall]

Would appreciate a second review here, but otherwise I'll merge it and cut a 1.1.0 in the next day: #18

[rkuykendall]

Seeking reviews: #20

[twisty]

Is this issue is closeable? If we close this it should encourage more specific issues going forward?

<aside>Really good to see this project on-the-move again. 💯👏</aside>

[aogaili]

Really nice community team work in bringing life back to this project!

@aesopwolf just for my understanding on how this worked, so you had access to publishing and adding contributor to npm right? basically the original repo was forked under new organization, then it got converted to standalone repo (to make more searchable), then you gave access to others to publish to npm?

[rkuykendall]

@aliogaili You can see the start of this here.

I thought I had the time to help bring this project back to life, but I haven't be able to help out nearly as much as I thought I could.

I just gave @maccuaa, @track0x1, @twisty, and @sdemjanenko access to the npm project. (You were just the first people that came to mind).

Lastly, this project should be converted to a github org, preferably https://github.com/formsy (but that's currently taken). So maybe https://github.com/formsy-react for the time being, @rkuykendall do you want to set that up? You could then invite those 4 people I mentioned above to be owners on the github org.

He then forked the repo into this organization. I had Github convert it to a standalone repo to remove a number of limitations, including search.

[aogaili]

Thanks for the details @rkuykendall

I find it fascinating the process of how an open source tech survives beyond all of it's original contributors, it seems that some open source tech is even more resilient then companies when they truly add value to it's consumers.

Thanks again for the effort, I'lll happily continue using formsy-react.

[rkuykendall]

All credit for the survival of formsy-react goes to @aesopwolf. Without their embrace of the community over the past two weeks, I would probably be researching alternatives right now. I think the project now, with so many active responsible owners, is extremely resilient.

[aogaili]

So if aesopwolf didn't have npm admin access and all those with publish access suddenly vanish then it means that a fork need to be published under another name which mostly like lead to the lack of adoption on npm. Is that true?

I'm asking because it seems that to ensure the survival of any open source npm project, it needs to have at least one active members with npm access, preferably more, when that member detects low activity, then he/she needs to start adding more responsible active members. Is that a valid takeaway?

[rkuykendall]

Yes, that is a very valid takeaway. If all members with NPM access disappear, the project must be forked and published under a new name. The issue is that the fork always has trouble gaining a critical mass to overtake the original. It happens, but it's not easy. The biggest fork that was gaining traction was formsy-react-2 by @maccuaa, but as you can see, despite being a great fork, this repo has already overtaken it in stars.

[maccuaa]

@rkuykendall Haha yes that's true. Probably a good thing though since I don't as much time as I wish I did to actively maintain it. Being a part of a team is definitely a better situation to be in than trying to keep an open source project going on your own.