CO-MAINTAINERS WANTED

[rowanwins]

This component has far outgrown my initial expectations and I'm not able to provide the amount of support that users require.

If you're in a position to and would like to help out with its maintenance and development please let me know.

People of any experience level welcome, I'm happy to do a bit of mentoring etc :)

Cheers
Rowan

[Olusiji]

Hi Rowan,

I'd love a chance to be a co-maintainer. My Vue skills are intermediate level, and I have some experience deploying Vue app for production although I would love some mentoring too.

Please let me know how I can be of help.

Regards.
Olusiji David

[rowanwins]

Hi @Olusiji

Thank you for your offer. If you could send me an email to me@rowanwinsemius.id.au that would be great and I'll fill you in!

[twickstrom]

Let me know if you are still looking for help

[Etheryte]

I would very much caution against transferring ownership of responsibility for a public repository as large as this. There are numerous cases of benign repo takeovers followed by malignant activity later on, for example the recent bitcoin miner fiasco on another large repository comes to mind.

There is a standard way to do this that doesn't put any of your current users at risk — let another repository grow organically. If someone is really interested in maintaining this project, they can fork it and start maintaining it, right away even.

If you want, you can even link to the said repository in the readme, but do not give write access to this repository. Otherwise you're putting unsuspecting end users at risk when they don't even know to look out for it — I doubt most of them are scouring the issue lists of every single one of their dependencies.

Having another repository and linking to it is the safest option: existing users don't pull someone else's work into their repositories unknowingly, yet can choose to manually check it out and update their dependencies once they have the need.

[pscheit]

@Etheryte never thought of this :o

[MatheusRich]

If anyone ever makes a fork of this, please comment here!

[Etheryte]

Since I'm familiar with this codebase, that of Dropzone, and the author of nuxt-dropzone, it seemed like a logical conclusion I would. It isn't a fork, but a new, improved approach to bundle Dropzone for Vue.

You can track progress at Etheryte/vue-auto-dropzone.

What it currently does:

• automatically maps all Dropzone methods and properties to a Vue component and library build time, i.e. no more manual mapping nor runtime mapping overhead;
• exposes all Typescript types, plus generated type hints for those that are missing from the official Dropzone types (there are surprisingly many);
• automatically handles slots without additional props, and more.

What it will soon also have:

• documentation with demos;
• package on NPM;
• SSR for Nuxt et al.

What's currently out of scope:

• direct AWS uploads as provided by this repo, would be more fitting as a plugin.

For those of you interested in a fork or an improved version, what additional features are you looking for?
Currently, the interfaces are kept either identical or nearly identical wherever possible to mitigate migration effort.

[i-defranca]

Hey there! I have never contributed before, but this has been very useful for me and I'm available if you still need help here.

[lacrioque]

Hey, i have some experience with vuejs and already a contributer to LimeSurvey.
I'd love to help here, too.

[JonUK]

Hi @rowanwins,

Are you still looking for co-maintainers for this repo?

[laminekalinko2]

Hey, I have some experience with vuejs and dropzone, I'd love to help. let me know if you need someone

[sudhakarselva]

Hi @rowanwins,
Please go through pull request and merge valid one..I would love to help,let me know.

[Ferhnir]

Seems not working with node@12

...
815 verbose stack Error: node-sass@3.13.1 postinstall: node scripts/build.js
815 verbose stack Exit status 1
815 verbose stack at EventEmitter. (C:\Users\Ferhnir\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\index.js:332:16)
815 verbose stack at EventEmitter.emit (events.js:223:5)
815 verbose stack at ChildProcess. (C:\Users\Ferhnir\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
815 verbose stack at ChildProcess.emit (events.js:223:5)
815 verbose stack at maybeClose (internal/child_process.js:1021:16)
815 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)
816 verbose pkgid node-sass@3.13.1
817 verbose cwd E:\wamp64\www\rmgl_v5
818 verbose Windows_NT 10.0.18363
819 verbose argv "C:\Program Files\nodejs\node.exe" "C:\Users\Ferhnir\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js" "install" "vue2-dropzone"
820 verbose node v12.14.1
821 verbose npm v6.14.4
822 error code ELIFECYCLE
823 error errno 1
824 error node-sass@3.13.1 postinstall: node scripts/build.js
824 error Exit status 1
...

but you can install on older versions of node, unfortunately most of my dependencies using now node 12+ :(

maybe some update for vue-dropzone ?

[superbiche]

@rowanwins you closed this but it still seems there are no maintainers. Is there a reason you closed it?

[vesper8]

I've enjoyed using vue-dropzone for years now but it seems like it's time to move on to something more maintained and more modern. As @Etheryte suggests in his improved version of vue-dropzone here: https://github.com/Etheryte/vue-auto-dropzone

I think we should all take a look at https://github.com/pqina/vue-filepond

I know swapping such a module is not easy task but it looks pretty fantastic so I'm switching over. Thought I would mention it here for anyone not already aware of this alternative

Cheers