FAQ

How do I subscribe?

We are happy you asked; it is very simple. Create an account on https://accounts.nativescript.rocks then click the subscribe button.

How do I unsubscribe?

It is very simple, Since all money is collected by Paypal, you need to log into your Paypal account, then click your account then view your active subscriptions and cancel it.

How does this help the community?

ProPlugins collects monies as a single source, and then directs approximately 80% of all monies gathered directly to the plugin authors, contributors and mergers. 20% covers the credit card/subscription processing fees, servers, and any administration. Apple and Google both charge 30% for just hosting your app; we are attempting to be less because we are trying to put as much money into the developers pockets as possible.

Why the Red Screen of Doom during installs of outdated plugins?

First, I wanted a cool acronym, anyone who knows me I use acronyms everywhere... Since, BSoD was already taken, we settled for RSoD. :D
There are several possible options for this; and let me explain them, and I think you will agree the RSoD was the best choice.

• I can do absolutely nothing - this means that even though I know that some of these plugins are totally broken, I don't let you know...
• I can warn you on every build/run of the application (Can you say overkill!)
• I can break the install process unless you pass a `--borked-plugins` command line. (Serious overkill, and would break CI's everywhere... )
• I can require you to hit "Y" or "ENTER" to continue. ( Ahahahahaha, not much better than --borked-plugins. )
• I can popup a dialog in the app on all dev builds -- (Holy crap, that would be annoying!)
• A single ONE TIME install notice, that attempts to get your attention, can be easily disabled for CI's and does not impact anything and is only seen the once during the point where you are install the potentially or known broken plugin.

If you read my blog; you can see why option 1, was out of the question. I cannot just stand by idly and let you not know how to solve an issue. Yes, this solution might not be the solution you want; but a large part of the community will be happy to know there is a solution to any of the issues if they run into them.

Option 2-5 are very annoying, at totally different levels -- Doing any or all of them would be a lot better for advertising! It is in your face every time, even bad advertising works! But our goal wasn't advertising; it was just to simply let you know you might run into issues; and you can find a solution here.

The RSoD is not meant to scare anyone; it is meant to get attention!!! How many people REALLY pay attention to what scrolls by during a NPM install? I know I don't unless it broke, so assuming we are paying any type of attention -- the red MIGHT catch the eye and cause us to scroll back and see what it said. Other colors would more than likely just be ignored.

So to inform you, it needed to be visible, but not be intrusive enough to actually impact anything or to continue to be annoying. This warning does have some applicability right now, as NS6 did break some things. But this warning is really meant for future proofing these unmaintained plugins. A couple months from now when the new iOS is released, or Xcode, or Android OS, or even NS7 (in the future) -- the plugin will be broken. Without, maintenance these plugins will become broken by one of these future changes. So the RSoD meets that criteria, and was chosen as the best way to convey to the users that state of the plugin they are installing, and a potential way to solve it.

How does this help me?

First you are helping all the plugin authors of plugins you use be able to maintain them. This means higher quality plugins for your app. Second, you are able to easily find working plugins because this is a curated list. Third you save time, money, and frustration knowing that a plugin you get from @proplugins should work out of the box.

How do I upgrade my dependencies?

This is very simple; you can either edit your package.json and prefix any plugins with @proplugins/ or you can de-install them via npm r --save plugin-name and then install the proplugin version with npm i --save @proplugin/plugin-name. We also have a handy upgrade page.

Why a subscription?

Over the last 4 years; several of us have tried a couple of the different ways to try and help pay for just the maintenance of our own plugins, and those methods have failed.

So the choices came down to:

• More community involvement, which in the last 4 years has been very low.
• Selling each plugin, seems very disruptive and brings costs up a lot, and increases the work for the authors.
• A subscription where we can keep costs low, because it is spread out over the community. Seems like the best choice for everyone.

Why not individual plugins / ala-cart?

There are several reasons we decided against ala-cart or picking and choosing plugins.

• First we would have to individually price plugins based on how much value we believe they offer the community. So something like ns-sqlite would be charged for more than say ns-globalevents.
• You might only need 5 plugins for this project today, but 10 tomorrow. If you only picked up the cost for 5 today; their might not have been the money available to have kept all the plugins in excellent well tested shape, for when you need 10 in tomorrows plugin. So some costs are to make sure all plugins stay in excellent shape for "tomorrow"
• This also makes taking money harder, now we have to have a shopping cart; & separate pricing, and potentially conflicts in how things are priced. Developer ego's are a real thing.
• Can cause developer infighting because "my" plugin brought in X dollars and yours only brought in Y dollars so it isn't fair that we are splitting X+Y in half, I'm going to go and do it myself....
• If Plugin X is solid, and Plugin X brought in a lot of the money, it might make people question why we are putting money towards Plugin Y. However, in your next project you might need Y, but now it is not maintained.
• Spreading the costs across the majority of the community allows us to bring down prices, because everyone pays a reasonable amount, but still below market value rate
• This allows you to pay a SINGLE fee that makes all of our plugins open source sustainable. This is a huge thing for companies who only want a single bill, Not 20.

Does this hurt the community?

Frequently, I've seen the response or question asking/stating this will hurt the community. However, the truth of the matter is this actually helps the community, as in all reality the only thing we did was add a new service.

If the community, disagrees with this NEW service:

• The community can still add issues/PR's to the repos as before. We will merge (untested) and publish them. So if the community wants to maintain them, they can.
• The github repos and npm installable versions are the same (plus any community PR's) as they were the day we announced ProPlugins
• We have not removed any access to any plugin that we FORKED and put into the ProPlugins

Second, if the community does NOT want to step up an maintain any of these plugins, we now have this awesome NEW service which takes care of the maintenance of them for you.

The community never actually looses anything, the community just gained another service.

What are the terms and conditions?

We honestly hate to do this, unfortunately for this to be a success for the entire community; we have to have some simple rules. First, we (the authors) cannot be competing with ourselves. If you put it in npm/github for free; where then is the support going to come from to continue maintaining and enhancing the plugins?

So we ask you as the authors; do not publicly fork our plugins.

By subscribing to this service, you acknowledge the following simple terms and conditions for this service:

• You will not share your account with anyone, it is yours alone. (unless it is a multi-seat license, then it is for the number seats)
• You will not share any of the plugins with any one that does not have an account (except, in your compiled applications).
• You will not create any open/public forks of any of these repos.
• You will not create any closed forks of these repos, to share with people that do not have an account.

Does this guarantee my issues will be fixed?

Nope, there is no actual fixed time table for all fixes. It really all depends on how much other work in the ProPlugins is going on.

• Because the contributors are paid per PR; the odds of plugins becoming bug free (including your fix) dramatically goes up.
• Because we strive to maintain bug free plugins; again the odds of any issues being fixed are extremely high
• A plugin can be removed for poor quality, this makes it more likely the team will fix any issues fairly quickly.

Does this guarantee my features will be added?

Nope, however, because the contributors are paid per PR; the odds of features being added (including yours) dramatically goes up.

Can I get a refund?

No, first all monies are distributed to the developers, and second this would just add to the costs of administration. We have tried to make the administration as cheap as possible so that the majority of the monies received can go to the developers.

NPM/TNS compatibility

Yes, ProPlugins is 100% compatible with your existing NativeScript tooling. Currently npm i --save @proplugins/name will work after one simple command line setup. The instructions are found on your subscription page.
The NativeScript/TNS command line as of v6.02 has a bug in the code; so tns plugin add @proplugins/name will currently fail. A PR has been submitted to fix this issue; and so hopefully they will release a version which works soon.

Logged in, still can't install plugin

Occasionally, NPM, after logging in, still does not set the proper information inside your ~/.npmrc file. In this file you should see a line that looks like this:
@proplugins:registry=https://npm.proplugins.org/
Please make sure it exists, if not just append the above line to your ~.npmrc file.

Can I share accounts (single user)?

We really hate to take a hard line here, but do to abuse by people and to keep things fair; the answer is NO! To keep our costs low, and to try and maintain all the plugins; ProPlugins needs revenue.

In fact, if an single user account accesses the NPM server from more than one ip in a short amount of time; your subscription will be terminated. No-refunds and an administration fee will apply to your account to reactivate it.

Do not share it with your friends, co-workers, boss, build/ci servers, etc. You should treat this as a single machine account.

You can contact us for site-licenses/seat license which do allow account sharing; but unless you have a non-single user account; don't do it!

What license are the plugins under?

All plugins are typically under the exact same open source license they were originally.

However, by joining this service you have some addition limitations on the distribution of these (see terms and conditions above).

We want you to use the plugins freely in any app you are building. We just can't compete with ourselves for free, and still continue to maintain them.

Can I fork the plugins?

Technically you, as a user, can clone them and put them in a repo. However, our licensing agreement, which you agreed to, only allows private repos. We ask you to respect our wishes as the authors of these plugins.
If you clone them, please put them in a closed / private repo. If you are attempting to fix an issue; please let us know and we will make sure you have access to fork it on git.proplugins.org into your own private namespace on git.proplugins.org.
By helping us, you help all of us maintain our service:

• We are asking you, as the authors and maintainers of these plugins, nicely not to make any public repos.
• We really don't want to have to go to a more restrictive license, to enforce it.
• We do not create any confusion to where the working/supported versions are at.
• We don't want to compete with ourselves!
• We want to encourage this community program, this will allow us to maintain even more plugins.

What are phases?

Phases are the different points where we release new groups of features.
For example; the initial release we consider as Phase 1.
This is where we get things working, get people subscribing and as many plugins tested as possible. It has certain requirements (like all plugins are required to have NS-Core demo and work in NS 6.)

Phase 2Is the next major step; these phases will come about really based on the number of subscriptions and time. If we get 1000's of subscribers this will allow more features planned in phase 2/3 to show up in phase 2. Less subscribers mean we have to cut features and push them to phase 3.

What features are we thinking about in Phase 2?

Phase 2, is where we would like all plugins to have:

• NativeScript-Vue demo
• NativeScript-Angular demo.
• All PR's by the author must now be reviewed by a second set of eyes.
• All Dependency license information in main license file
• Plugins.NativeScript.Rocks integration
• Consistent documentation

What features are we thinking about in later Phases?

We would like all plugins to have:

• React-NativeScript demo (Depending on maturity)
• Svete Native demo (Depending on maturity)
• Automated testing
• Playground integration
• Demos runnable/launchable from web
• All ProPlugins features self-contained (i.e. no more accounts.nativescript.rocks)

What plugins do you have?

We have a slew of plugins from various authors at launch, with hundreds of fixes and enhancements to them. Everything from minor tweaks, to making the plugin actually work in NativeScript 6.x & 7.x

You can view our NPM server without an account; https://npm.proplugins.org, please note that this list may change at any time.