[suggestion] Update the repository to follow the NativeScript plugin seed structure and workflow

[VladimirAmiorkov]

It would be great to update this repository to the NativeScript plugin seed structure to enable:

• Better plugin development workflow with NativeScript 6.0.0 (webpack takes care of all tsc, you simply start the app with a single tns run)
• Common structure, well known in the NativeScript community which will allow for faster and easer contributions
• Easer future issues resolutions since NativeScript plugin seed can be used as a reference for future changes

[PeterStaev]

The plugin seed structure if far from ideal, and I personally dislike it, like it is now. The main thing being that the README that is in the root is some dummy and the actual README/docs is in the src folder. I think this is very inconvenient if someone lands on the repo users should go in and dig the actual docs/readme instead of seeing them directly on the "home page".

Second thing is that I'm a bit afraid to leave TS compile purely to webpack, since at the end when you publish the plugin you compile with simple TSC and not webpack and this can have its difference like I have experienced (NativeScript/nativescript-dev-webpack#1012). So while you are testing you might think everything is working, while in the end when you compile with tsc the resulting code might not be working as expected.

[VladimirAmiorkov]

The location of the readme in the seed is something that we can have a discussion about but this alone as a reason to not follow a common plugin development structure to me looks like a fairly small reason. This can always be handled additionally (per plugin's repo) with a single build script that moves it from the root to the package before packing for npm, this is just the first idea that comes to mind.

Regarding the second concern while the ongoing discussion of NativeScript/nativescript-dev-webpack#1012 is still going I cannot comment on that as an issue that is related to anything the Plugin seed provides. If this is the case then the plugin seed will also make changes accordingly to resolve it and if this repo follows its structure it will be fairly easy to update it with those fixes.

The overall benefit of following the plugin seed as it is at the moment is that it gives the community a "common ground" when viewing and deciding if they can contribute to an open source plugin since they don't need to spend time getting to know each plugin repo's workflow but rather spend their time working on the fix they want to contribute. Is the plugin seed perfect, definitely not but nothing is, is it helpful to increase contribution between plugins, I personally think definitely yes.

If you have any ideas how the plugin seed can and should be improved please let us know by adding an issue here. We are constantly looking into ways we can make the plugin development experience/workflow a breeze for everyone.

[PeterStaev]

I tend to disagree on your last comment. There are many plugins out there that follow the plugin seed, yet they do not get much more community contribution than this. So the common structure is the least thing that would bring more community PRs to plugins.

Second thing this plugin structure/workflow has worked since NS was in beta for all my plugins with very few changes. Yet the plugin seed is constantly changing (looking at the amount of commits). This is not a bad thing, but now not only you have to keep up with the updates of NS itself, but you also need to update/change based on the changes in the plugin seed. I find this rather unacceptable effort.

Third - like I tried to explain pointing to the webpack issue - using webpack directly to compile the plugin code with the demo apps is not equivalent of using the JS code of the plugin itself in a project. If we are distributing the plugins in TS or webpack compiled, it would be, but with the current state it is not and there are actual differences. And using it like this just mask problems that could be caught by simply separately compiling the plugin code

So to sum it up:

• I am ok with changing the directory structure so that it resembles more or less that of the plugin seed
• I am not ok with having the README in the sub src folder. The whole documentation should be visible in the root.
• I am not ok with using automatically webpack for the compilation/dev test of the plugin code for the above mentioned reasons.

[VladimirAmiorkov]

Let's agree to disagree on the point if a common structure can and would bring more contributions. I fail to see how a common anything would not lead to easier and bigger communication but this is a topic to which it is next to impossible to get a final agreed upon answer.

True, changes are inevitable while we truly try to no make such NativeScript is in its 6 version and as a product uses many third party deps which bring constant changes that needs to be handled on our side. This is true for any open source project that uses open source deps, we either have to make changes to face a reality where our deps are outdated due to not wanting to make changes and improvements. I get our point and after an internal discussion I can agree that the plugin seed can and should be improved, I like your idea of a dedicated location (dist folder) to which the JS files to be located after a tsc, I like it that much that I already added a similar issue as an improvement suggestion a month ago :) .

This is something that is being discussed internally before NativeScript 6.0.0 was officially released and we are doing our best to address it in a way that would not compromise the performance improvements made with 6.0.0. One easy solution would be to:

• Manually trigger tsc on your plugin's source code (maybe we can make a CLI hook to do that when triggering tns run)
• Have the JS files output in a "dist" folder
• Use that dist folder as symlink in your demo apps
• Make changes to your TS files and have your manual tsc do the compilation and the CLI to sync them from the "dist" folder

As you can see this is more or less the same as this plugin's structure which is awesome. I would have loved to see this as a suggestion over at the Plugin seed issues as it is something that can solve a lot of issues and be something that the community wants. Do not hesitate to add such suggestions to our repos in the future.

For now I would like to experiment the above idea in the plugin seed to see if it will limit the things the Plugin seed does and if not I do not see a reason not to adopt that in the Plugin seed, after all the idea and goal of the seed is to be useful for the community. Feel free to leave this issue open but mark it as "discussion" while we clear things out.

[PeterStaev]

I think you misunderstood me - I'm 100% for common structure and I agree that the common structure will make it easier for contribution. What I meant is that I don't see it (from past years) having this effect for the NS community, sadly :( But also this common structure must be really solid and have least amount of changes, only may be between major versions of NS so that it doesn't double the efforts of updating plugins. And this is not what I see in the plugin seed.

The reason why I haven't added any suggestions is that I never personally used the plugin seed myself, I have only "experience" by viewing it in other plugins. I promise you that for the next plugin I make, I will use the plugin seed so I can get a first hand experience and will log any suggestions to GH 😄

[VladimirAmiorkov]

Personally I have been involved with NativeScript plugins for years and before having any kind of common structure, contributing to other persons plugin was much much harder and usually involved around 30-60 minutes of preparation time before starting any kind of work. For some this is a show stopper for some it is not, will a common structure and workflow give you a lot of contributions, no one can say for sure but it will for sure help in some way. Yes if implementing a common structure takes too much time during the plugin's life time that is a problem and it needs to be addressed. I can say that for the plugins I have and I am working on, keeping up with the plugin seed takes very few of my time but brings me a common workflow which if not present would otherwise take much much more of my time in preparation time.

I understand, the Plugin Seed is something that was not widely exposed to the community due to it being in development and mainly being in design discussions to make sure it works for every kind of plugin's workflow and development requirements. This is why many of the older plugins did not start with it and are not using its structure, it would be great if we can update them to it but that costs with time and willingness.

I hope we can make the Plugin seed fit all scenarios and help out all of the plugin authors to not struggle with coming up with unique workflows so they get more efficiency and fun during plugin development and maintenance.