Review & Testing

[keerl]

I finally have this at a point where I would like some review and testing done.

Here are the things I would like tested:

• Building the plugin (from README instructions)
• Test all demos (Angular, React, Svelte, and Vue)
• Test demos in development mode (see README)
• Setup and run Detox e2e testing (after setup run npm run e2e)
• Mess around with formatting/linting. Change code in demos or wherever and see if VSCode auto fixes or run linting commands (see npm scripts).
• Generate plugin docs (see README)

What are you overall thoughts/concerns?

[cvietor]

Hi there, i'd like to share my thoughts about the community plugin seed. I'm aware of the discussion about pro's and con's of the official nativescript plugin seed (new monorepo version) and this one and in my opinion both are good and could benefit from each other in certain cases. but this issue is about the community plugin seed, so of course i will try to focus on this one :)

a few thoughts about the use case of this one:

• establish & maintain a standard for @nativescript-community scoped plugin packages, so that maintainers/contributors do not need to constantly worry about different develop-, build- or publishing workflows or overall structure across multiple repositories.

what i like:

• single repository instead of monorepo
  • i also like the monorepo approach, however i think for community plugins, one repo per plugin fits better
• docs generation baked into the plugin-seed template
• e2e support build-in

my concerns:

• demo projects for all framework flavours build-in (except nativescript core?)
  • seems like a lot of overhead to me in many ways for a lot of plugins. i.e. the ui-mapbox currently does not have framework specific components/modules/stuff so it would only be different markup/same code, which leads to a lot of duplication and code to maintain. even if a plugin has framework specific stuff, it still requires high maintenance. same would apply when it comes to updating the demo projects, that's a point where the official plugin-seed makes a good job in terms of updating dependencies, sharing demo code, etc.
• overall quite a few changes / removal necessary when you want to get rid of
  • a framework flavour demo
  • e2e

i haven't had the time to really try it out yet, will post additional feedback when i did. but wanted to get the discussion started :-)

last but not least, thank you @keerl for the awesome work and the effort you put into this one, highly appreciated!

[keerl]

@cvietor Thanks for your feedback! Here are a some of my thoughts:

• I didn't add a vanilla JS demo because @farfromrefug told me that vanilla JS/TS support will be removed somewhere down the line and I didn't want to spend time making a demo that will be deprecated someday.
• I understand it can be a pain (or redundant) to maintain 4 different demos flavors. But what's the best solution? Just 1 specific flavor? Shared demo code would be great, but I don't really know how that would work. I don't want to instantiate everything through JS, because I know a lot people look at the demo code for their flavor to see how they can implement it in their project, and the implementation will look different on every flavor simply because the framework syntax is different. I'm open to any ideas here.
• Removing any demo or e2e testing should be as easy as just deleting the directory and removing any scripts or imports in the main package.json.

I guess my overall thoughts are this doesn't have to be a set-in-stone follow all the rules plugin seed. It's just a place to start and has everything you would need. Don't want all 4 demos? Delete them. Don't want e2e testing? Delete it, etc.

Just my thoughts. Everyone has their own style and preferences when it comes to this stuff and because these are community plugins it should allow for developer freedom.

[farfromrefug]

@keerl @cvietor just to be clear and I ll respond about the rest later. Core XML could be removed or at least n9t supported anymore. It was suggested. But don't spread it as a fact ! I think it is much easier to work and develop flavors. That.should.be the main reason why we keep only flavors. In my mind demos should not be to do copy paste they are here to show what you can achieve. Everyone should take the time to read the code . they it should be almost self explanatory to port to your flavor. Will answer about the rest later

[keerl]

I'm going to spend some more time reworking parts of this. Let's put this review on hold because I think I can make things a lot better still.

[cvietor]

@keerl if you need a helping hand, ping me at slack!