Review & Testing - Round 2

[keerl]

Hey guys (@farfromrefug @cvietor),

Sorry it has been so long since I've made any updates to this. Been really busy the last month and have been thinking a lot on how to make this better.

What I ended up doing is moving all of the demos into their own submodules. That way we have the exact same demo for all plugins so when we have to make updates we only have to do it once and then just update the submodule hash in every plugin.

The demos in the submodule don't actually contain anything specific to a plugin. It is a generic menu template that is ready to have plugin demo snippets "attached" to it.

To add actual plugin demos to it, I now have a "demo-snippets" directory with a subdirectory for each flavor. Inside each flavor directory is the actual demo code you want to run in the top-level demo. These folders will then by symbolically linked to the demos. Then you can run the demos normally and it will seem like these components are part of the demo, but are not actually committed to that repo.

There is an "install.ts" file in each flavor which contains an "install()" function that is ran on startup and that's where you put any code needed to register the plugin with the demo. It also says what components you want to add to the demo.

You can also add/modify package.json dependencies with the package.json in the "demo-snippets" directory. That way if the plugin needs additional packages that the top-level doesn't have, you can add them.

I am very happy with how this turned out and think this can make life way easier and consistent across community plugins.

When you have some time, please read through the README and test it out. Just remember to clone the repo recursively (--recursive) to download the submodules as well.

Please let me know what you think! I also have been working on a branch of ui-collectionview where I converted it to this seed. If you want to see it in a real example I can push it up. Here's a link to it if you want to see it being used in a real example. https://github.com/nativescript-community/ui-collectionview/tree/feature/plugin_seed

FYI, I removed e2e testing for the time being. I'm still trying to figure out the best way of implementing that. Having a "tools" submodule opens a lot of possibilities because we can make utility scripts to help out with anything.

[farfromrefug]

@keerl amazing job! Sorry i dont have the time to really test it right now. Too much work...
But i want to say the readme is really well done and very explicit.
Will try and look at the rest later.

[cvietor]

@keerl thank you very much! same here, i need a few more days to get into a healthy work-lockdown-childcare-life balance :-)

[farfromrefug]

@cvietor @keerl had a though. In some case, but not all cases, the plugin seed need to be a mono repo thing. Just like the N seed.
Should we make the plugin seed the same way with only one package?
That way we would have the same plugin seed for everyone. Not many changes:

• "outDir" is now packages/name instead of plugin
• build script in the main package.json simply calls lerna and actual build scripts are in packages/.../package.json (which i dont like by the way, would like the npm package.json to have no dev script!)

What s your thought?

PS: i will migrate collectionview into a multiple packages one. I think mapbox will end up being the same

[keerl]

I'm fine with adding the ability to have multiple packages in the plugin seed. Would it pretty much be like ui-material-components is? A subdirectory for each package in src and packages directories with a package.json and tsconfig.json in each package?

[farfromrefug]

@keerl yes. My question is do we do that by default with only one package.
I wanted to check if calling lerna run build was slower than npm run build for a single package.
I want everything to be easy for a single package repo.

[farfromrefug]

@keerl working with it right now. Trying a plugin with it:

• will the plugin "package" will be added to the demos package.json files? Not here as i clone to get it

• we need to figure out the "typings" errors when using the demo-snippets directly. Maybe add the "flavors" dependencies to the root?

• webpack configs should not be in the demo. N will add them. If you want custom webpack thing create an app.webpack.config.js which requires the normal one. This is what i do almost everywhere.

• will the name of the plugin be "auto" replaced all over the place? like package.json, readme (this one i think yes) ....

• remove the changelog from plugin dir. Will be generated

• the demo go by default to "development". they should go there only with --env.development

• the eslint config is wrong it is missing in 'prettier' in plugins

• remove everything from the .prettierignore it breaks lint and fix from demos (gets picked up when inside demos thus ignoring everything in demos...)

• N current webpack config wont work within our demos because resolve.symlinks is set to true thus symlink resolved thus error because outside of root folder. And thus wont find some deps like nativescript-vue

All that being said it is really cool. Feels like it is much easier to handle it all!

I ll try and push some changes. Will also update the geocoding plugin with the seed!

[farfromrefug]

also the docs folder needs to be cleaned up. It fails because the dir is not "empty"

[keerl]

The plugin package gets added to the demos package.json when you run npm run demo.setup. The packages are not actually committed to the demo package.jsons.

Are you talking about the errors in VS code when you open code in the snippets? Yeah I don't know a way to fix that. The only way I have to deal with that is to actually edit the files in the symbolic link version of the files (demo-vue/app/components/linked-components/...) and everything works well in VS code.

I will have to create a custom webpack config because that is what I use to have the auto-redirect to the development demo.

I don't have any auto replace script for the name of the plugin...yet...

Did it not redirect to the development demo because you removed the webpack config?

Eslint errors make sense, I forgot to update those.

Are you talking about the new NS webpack? Because the current files work for me with the symlinks.

[farfromrefug]

@keerl ok for the demo setup did not run it.
yes there are those vscode errors from the snippet dir (which i will try to fix) but this is not what i am talking about.
i am talking about build errors.

About your redirection to development you used NODE_ENV. Dont, use a custom variable defined in your webpack config (on top of N one). not good to sue NODE_ENV when we are not in a node env :D

I might see those symlink error because i am on macos, what are you on?

[keerl]

What are the build errors you are encountering?

I really don't know much about webpack, so I didn't know the best way to do the redirect. I'm sure you can figure out a way better way to do it.

I am on mac os too and I don't think I see those errors. When you try to run the actual plugin-seed (with the committed webpack) do you get that error? Could you attach that?

[keerl]

Also, looking at your updates so far on https://github.com/nativescript-community/geocoding

The demos (and tools) should be added as a submodule and not cloned into the repo. This should be done with git submodule add https://github.com/nativescript-community/plugin-seed-demo-ng.git and same thing with all other demos and tools

[farfromrefug]

@keerl yes i know about the issue in geocoding. This is due to the way i did it. because i wanted to kep the original repo history. Will fix it! thanks
For me simply the demos wont build if i use N webpack config. Yours work exactly because resolve symlinks is set to false

[keerl]

The webpack stuff should be fixed now. The webpack will be generated by the NS project, but then each demo has a custom file which fixes the symlink issue as well as adds a custom variable to hold the "development mode" instead of NODE_ENV.

I also decided to remove the docs directory. There is no reason to store the actual empty docs in this template repo. One can just run the generate docs to create them.