New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: TNS plugin create <xyz> [--template <plugin template name] #1945

Open
NathanaelA opened this Issue Jul 23, 2016 · 21 comments

Comments

Projects
None yet
10 participants
@NathanaelA
Contributor

NathanaelA commented Jul 23, 2016

I worked on a plugin template that would make making plugins a whole lot easier. Basically it would generate everything you needed for a JS or TS plugin ; including creating the package.json, .gitignore, .npmignore and basically have a plugin fully ready for publishing after it was done. (It uses a post-install script to ask questions about the type of plugin, repo, name, etc).

However, do to the issue with the #1932, we cannot use the normal tns create MY-PLUGIN-NAME --template plugin to use the template.

This is a feature request either to allow the package.json change like suggested in #1932 (i.e. something like an additional key {"cleanTemplate": "true"}
Another idea Nathan Walker suggested; was a new tns plugin create [--template ]

@tjvantoll

This comment has been minimized.

Show comment
Hide comment
@tjvantoll

tjvantoll Aug 15, 2016

Contributor

I personally sort of like the idea of tns plugin create [--template], just because I personally would expect the existing tns create to only build new projects, not plugins. Regardless of implementation details, I think this would be a hugely valuable feature to have baked into the {N} CLI, as it could help establish an “official” structure for our plugins, as well as lower the barrier to entry for new plugin authors.

Contributor

tjvantoll commented Aug 15, 2016

I personally sort of like the idea of tns plugin create [--template], just because I personally would expect the existing tns create to only build new projects, not plugins. Regardless of implementation details, I think this would be a hugely valuable feature to have baked into the {N} CLI, as it could help establish an “official” structure for our plugins, as well as lower the barrier to entry for new plugin authors.

@radeva

This comment has been minimized.

Show comment
Hide comment
@radeva

radeva May 9, 2017

Contributor

Hi @NathanaelA @tjvantoll

We are now working on a plugin seed repo which users will be able to clone and use as a starting point for their plugins. We plan to make it public soon. I hope this approach will also be beneficial for the plugin authors.

Contributor

radeva commented May 9, 2017

Hi @NathanaelA @tjvantoll

We are now working on a plugin seed repo which users will be able to clone and use as a starting point for their plugins. We plan to make it public soon. I hope this approach will also be beneficial for the plugin authors.

@dtopuzov

This comment has been minimized.

Show comment
Hide comment
@dtopuzov

dtopuzov May 9, 2017

Member

I don't think we should add extra code in CLI just to solve something that can be done with
git clone <official-plugin-seed>.

Member

dtopuzov commented May 9, 2017

I don't think we should add extra code in CLI just to solve something that can be done with
git clone <official-plugin-seed>.

@dtopuzov dtopuzov closed this May 9, 2017

@NathanaelA

This comment has been minimized.

Show comment
Hide comment
@NathanaelA

NathanaelA May 9, 2017

Contributor

I totally disagree with both of these decisions.

Contributor

NathanaelA commented May 9, 2017

I totally disagree with both of these decisions.

@tjvantoll

This comment has been minimized.

Show comment
Hide comment
@tjvantoll

tjvantoll May 10, 2017

Contributor

I also disagree. Although simple, I think a tns plugin create command will really help plugin authors. Sure the command will just git clone the seed, but from a plugin author’s perspective you’re saving me from needing to find the appropriate repo (which the average user probably doesn’t even know exists), running git clone, and also dealing with folder names. (The folder name will be nativescript-plugin-seed by default, and that’ll be a hassle to change.)

I believe tns plugin create MyPluginName will make plugin developer’s lives a lot easier, and I believe we should add it.

Contributor

tjvantoll commented May 10, 2017

I also disagree. Although simple, I think a tns plugin create command will really help plugin authors. Sure the command will just git clone the seed, but from a plugin author’s perspective you’re saving me from needing to find the appropriate repo (which the average user probably doesn’t even know exists), running git clone, and also dealing with folder names. (The folder name will be nativescript-plugin-seed by default, and that’ll be a hassle to change.)

I believe tns plugin create MyPluginName will make plugin developer’s lives a lot easier, and I believe we should add it.

@dtopuzov dtopuzov reopened this May 10, 2017

@jlooper

This comment has been minimized.

Show comment
Hide comment
@jlooper

jlooper May 10, 2017

I am posting my vote in favor of the CLI modification in support of TJ and Nathanael. Look at it this way - we want to make it easy for people (like me) to make plugins. Right now, this job is really daunting because there's no clear path to create a plugin. We're going to fix that by creating an official seed. Great, then let's onboard people super easily to our seed repo by integrating it into the CLI. Seeing as how you really can't ship an app without at least one plugin, let's make it as easy as possible to allow people to create them to make our plugin marketplace that much stronger. More and more plugins will be created using our seed, so upgrading them will be less and less problematic. This is a long-term maintenance win for the community.

jlooper commented May 10, 2017

I am posting my vote in favor of the CLI modification in support of TJ and Nathanael. Look at it this way - we want to make it easy for people (like me) to make plugins. Right now, this job is really daunting because there's no clear path to create a plugin. We're going to fix that by creating an official seed. Great, then let's onboard people super easily to our seed repo by integrating it into the CLI. Seeing as how you really can't ship an app without at least one plugin, let's make it as easy as possible to allow people to create them to make our plugin marketplace that much stronger. More and more plugins will be created using our seed, so upgrading them will be less and less problematic. This is a long-term maintenance win for the community.

@rosen-vladimirov

This comment has been minimized.

Show comment
Hide comment
@rosen-vladimirov

rosen-vladimirov May 10, 2017

Contributor

Hey all,

Thanks for sharing your feedback. The issue will remain open and we'll try to prioritize it for a future release. There are other tasks on the board, so I cannot give an estimate when this one could do it. Of course, we'll be glad to help and review a PR that adds this functionality. It should be pretty straightforward to add the new command, so anyone can give it a try.

Thanks again and please accept our apology for the whole disruption. Your opinion is important for us!

Contributor

rosen-vladimirov commented May 10, 2017

Hey all,

Thanks for sharing your feedback. The issue will remain open and we'll try to prioritize it for a future release. There are other tasks on the board, so I cannot give an estimate when this one could do it. Of course, we'll be glad to help and review a PR that adds this functionality. It should be pretty straightforward to add the new command, so anyone can give it a try.

Thanks again and please accept our apology for the whole disruption. Your opinion is important for us!

@PeterStaev

This comment has been minimized.

Show comment
Hide comment
@PeterStaev

PeterStaev May 11, 2017

Contributor

I personally tend to agree with @dtopuzov comments. I do not see much benefit from a special CLI command compared to just cloning a plugin seed repo (like this one)

Contributor

PeterStaev commented May 11, 2017

I personally tend to agree with @dtopuzov comments. I do not see much benefit from a special CLI command compared to just cloning a plugin seed repo (like this one)

@NathanaelA

This comment has been minimized.

Show comment
Hide comment
@NathanaelA

NathanaelA May 11, 2017

Contributor

@PeterStaev That is because I assume you haven't seen what my plugin generator can do. ;-)

This is what I currently do: plugin create somename

It will then ask you the authors name and email address (if it hasn't cached this from a prior creation). It will ask you which license you would like this plugin under, it will ask you if it is typescript or javascript plugin, and if it is a split or combined plugin.

So only a couple questions, but once it has that information:

  1. It will create the folder "nativescript-somename",
  2. It will automatically create all the JS or TS files needed.
  3. It will automatically create the license file and documentation (which can be optionally read from a custom cache, in case you have your own documentation format, rather than the default format. And it will automatically do {{REPLACEMENT}} variables with all the values you chose (& those cached)... So your docs could say This plugin is under the {{LICENSE}} license and the documentation generated will say whatever license you chose. ;-)
  4. It will automatically create the .gitignore and .npmignore files customized for JS or TS (depending on your choices)
  5. It will automatically create the package.json format in the proper format for again TS or JS; with all rules to build and to run the demo. This includes the NativeScript keys, typings key, author key, and other keys that people FREQUENTLY mess up.
  6. It will automatically create the demo application, all per-configured for your plugin.

Yes, you can DO all these steps manually; but one command and I'm done, and it is consistently build; and I don't have to delete the .git folder to make it into a new repo, I don't have to touch the package.json file, My docs are complete except for the instructions specific to this new plugin.

This is what tns create --template plugin was supposed to do a YEAR ago. (Other than I ran into the issue that tns destroys the structure, hence this bug report to either add a optional flag so that tns won't mangle the output or a new command that works like the create command but won't mangle the template...

My question is which is simpler to get more people involved in creating things with NativeScript? Everything pre-created and ready to go like tns create application does, or should we make TNS simpler and eliminate the "create" command and then just start requiring new people to git clone an application repo, move things around, fix up the package json file and plist/manifest up and then install the other parts manually just to make a application? ;-)

Contributor

NathanaelA commented May 11, 2017

@PeterStaev That is because I assume you haven't seen what my plugin generator can do. ;-)

This is what I currently do: plugin create somename

It will then ask you the authors name and email address (if it hasn't cached this from a prior creation). It will ask you which license you would like this plugin under, it will ask you if it is typescript or javascript plugin, and if it is a split or combined plugin.

So only a couple questions, but once it has that information:

  1. It will create the folder "nativescript-somename",
  2. It will automatically create all the JS or TS files needed.
  3. It will automatically create the license file and documentation (which can be optionally read from a custom cache, in case you have your own documentation format, rather than the default format. And it will automatically do {{REPLACEMENT}} variables with all the values you chose (& those cached)... So your docs could say This plugin is under the {{LICENSE}} license and the documentation generated will say whatever license you chose. ;-)
  4. It will automatically create the .gitignore and .npmignore files customized for JS or TS (depending on your choices)
  5. It will automatically create the package.json format in the proper format for again TS or JS; with all rules to build and to run the demo. This includes the NativeScript keys, typings key, author key, and other keys that people FREQUENTLY mess up.
  6. It will automatically create the demo application, all per-configured for your plugin.

Yes, you can DO all these steps manually; but one command and I'm done, and it is consistently build; and I don't have to delete the .git folder to make it into a new repo, I don't have to touch the package.json file, My docs are complete except for the instructions specific to this new plugin.

This is what tns create --template plugin was supposed to do a YEAR ago. (Other than I ran into the issue that tns destroys the structure, hence this bug report to either add a optional flag so that tns won't mangle the output or a new command that works like the create command but won't mangle the template...

My question is which is simpler to get more people involved in creating things with NativeScript? Everything pre-created and ready to go like tns create application does, or should we make TNS simpler and eliminate the "create" command and then just start requiring new people to git clone an application repo, move things around, fix up the package json file and plist/manifest up and then install the other parts manually just to make a application? ;-)

@PeterStaev

This comment has been minimized.

Show comment
Hide comment
@PeterStaev

PeterStaev May 11, 2017

Contributor

@NathanaelA , I have neither used the plugin seed nor your command, as I have my own seed 😄

Now all those steps you listed are basically down to:

  1. Clone the seed repo
  2. delete the .git folder
  3. rename the ts/js files
  4. Change package.json with names, license, TNS version, owner.

And those steps are like <1% of the dev time you spend on a plugin 😄 If needed those steps can be automated via a npm script inside the plugin seed repo. If you are concerned about visibility of the seed repo, this can simply be added as links in the plugin docs, which authors will need to read either way if they want to start a plugin.

The question here is whether or not this whole thing should be part of the CLI, and IMO it should not be. Let's take a look at the competitors (Cordova/Ionic/ReactNative) - from what I see none of them have a command to create a plugin.
And you can't really compare creating an app to creating a plugin, because creating an app is done by thousands of different users, where the creation of plugins is done by handful of people. And in most cases normal users that create apps will not need to create a new plugin as there are already quite a lot available.

Contributor

PeterStaev commented May 11, 2017

@NathanaelA , I have neither used the plugin seed nor your command, as I have my own seed 😄

Now all those steps you listed are basically down to:

  1. Clone the seed repo
  2. delete the .git folder
  3. rename the ts/js files
  4. Change package.json with names, license, TNS version, owner.

And those steps are like <1% of the dev time you spend on a plugin 😄 If needed those steps can be automated via a npm script inside the plugin seed repo. If you are concerned about visibility of the seed repo, this can simply be added as links in the plugin docs, which authors will need to read either way if they want to start a plugin.

The question here is whether or not this whole thing should be part of the CLI, and IMO it should not be. Let's take a look at the competitors (Cordova/Ionic/ReactNative) - from what I see none of them have a command to create a plugin.
And you can't really compare creating an app to creating a plugin, because creating an app is done by thousands of different users, where the creation of plugins is done by handful of people. And in most cases normal users that create apps will not need to create a new plugin as there are already quite a lot available.

@NathanaelA

This comment has been minimized.

Show comment
Hide comment
@NathanaelA

NathanaelA May 11, 2017

Contributor

@PeterStaev - But my question is why have all the extra steps, training and burden for someone wanting to create a plugin. If you are brand new at creating plugins, having the entire framework automatically created so that all you have to do is focus on the plugin source eliminates a lot of hurdles. This can only be a good thing.

Second, there is a wide number of different errors from people in this area; I see them on a first hand basis because of all my work with the two plugin sites. You might be surprised at how many different ways people can mess it up... I have a LOT of extra code to deal with these issues in the plugin processing systems on the two plugin sites, and I have a large stack of issues I would love to automatically detect that I haven't had the time to program in the code to auto-detect them. That is how easily things are botched in this area...

According to nativescript.rocks, you are the 10th top author with a credit of 7 plugins, to date. I grabbed the FIRST plugin in your list and guess what. You have at least 2 mistakes you made in it. I only preformed a really quick glance, you might have more, and all your plugins might even suffer from them, no idea, my goal wasn't to embarrass you. My plugin template would have eliminated at least those two issues I found. So please explain to me how a new users is going to do it correct, when you; a top 10 plugin author; makes these mistakes? You don't exactly make a good case against it; when even you don't do it correctly. ;-) (Don't worry, your in good company, I've made these mistakes before on my plugins, and the NS team has made these mistakes before. However, I haven't made these mistakes in the last year when I let my generator create the entire scaffolding, and that is one of the primary points for having it available!)

Third, just because another vendor doesn't do something, does not mean we shouldn't do something. That is a faulty argument.

And your final argument is very much like 3rd, just because only a handful of people are doing it doesn't mean we shouldn't try and make it easier on them and on new people who want to do it. By having at least the scaffolding completely generated we will hopefully encourage more plugin developers. I would also disagree with the number of plugins, I am constantly running into places where a plugin doesn't exist, yet. I have a todo list of plugin that seems to be growing rather than shrinking... I want to encourage more plugin developers.


Just to make sure we are clear. -- I do NOT expect Progress to create a plugin scaffolding system, all I am asking for it that we either add a flag so that TNS won't mangle the template I pass to it via the tns create xyz --template plugin flag , or a new command/sub-command that will install a template without MANGLING the template.

ALL I want Progress to do is allow me to eliminate the mangling of a template, nothing else!

Yes, this feature will allow me to distribute what I consider a cool standardized plugin templates; but it will allow others to generate other types of templates (theming, pre-cooked apps, PWA's, better integrated web/angular templates) if they so desire and that is the POINT of this feature request to allow more things to be available to the community.

Contributor

NathanaelA commented May 11, 2017

@PeterStaev - But my question is why have all the extra steps, training and burden for someone wanting to create a plugin. If you are brand new at creating plugins, having the entire framework automatically created so that all you have to do is focus on the plugin source eliminates a lot of hurdles. This can only be a good thing.

Second, there is a wide number of different errors from people in this area; I see them on a first hand basis because of all my work with the two plugin sites. You might be surprised at how many different ways people can mess it up... I have a LOT of extra code to deal with these issues in the plugin processing systems on the two plugin sites, and I have a large stack of issues I would love to automatically detect that I haven't had the time to program in the code to auto-detect them. That is how easily things are botched in this area...

According to nativescript.rocks, you are the 10th top author with a credit of 7 plugins, to date. I grabbed the FIRST plugin in your list and guess what. You have at least 2 mistakes you made in it. I only preformed a really quick glance, you might have more, and all your plugins might even suffer from them, no idea, my goal wasn't to embarrass you. My plugin template would have eliminated at least those two issues I found. So please explain to me how a new users is going to do it correct, when you; a top 10 plugin author; makes these mistakes? You don't exactly make a good case against it; when even you don't do it correctly. ;-) (Don't worry, your in good company, I've made these mistakes before on my plugins, and the NS team has made these mistakes before. However, I haven't made these mistakes in the last year when I let my generator create the entire scaffolding, and that is one of the primary points for having it available!)

Third, just because another vendor doesn't do something, does not mean we shouldn't do something. That is a faulty argument.

And your final argument is very much like 3rd, just because only a handful of people are doing it doesn't mean we shouldn't try and make it easier on them and on new people who want to do it. By having at least the scaffolding completely generated we will hopefully encourage more plugin developers. I would also disagree with the number of plugins, I am constantly running into places where a plugin doesn't exist, yet. I have a todo list of plugin that seems to be growing rather than shrinking... I want to encourage more plugin developers.


Just to make sure we are clear. -- I do NOT expect Progress to create a plugin scaffolding system, all I am asking for it that we either add a flag so that TNS won't mangle the template I pass to it via the tns create xyz --template plugin flag , or a new command/sub-command that will install a template without MANGLING the template.

ALL I want Progress to do is allow me to eliminate the mangling of a template, nothing else!

Yes, this feature will allow me to distribute what I consider a cool standardized plugin templates; but it will allow others to generate other types of templates (theming, pre-cooked apps, PWA's, better integrated web/angular templates) if they so desire and that is the POINT of this feature request to allow more things to be available to the community.

@PeterStaev

This comment has been minimized.

Show comment
Hide comment
@PeterStaev

PeterStaev May 11, 2017

Contributor

@NathanaelA , read my previous comment very carefully. I did not say that I'm against having a seed template. I said that IMO its place is not in the CLI. So I'm all for @radeva's idea to create a unified template which others can use to create plugins. But IMO its place is not in the CLI.

As for plugin errors - your whole comment is irrelevant as adding the CLI option will neither magically sanitize existing plugins from their problems, nor will force the creation of future plugins using this option/template. This can easily be handled by adding some plugin developer portion to the plugins site where authors can check if there are any problems with any of their plugins (if it is really that important and could cause problems with usage).

Contributor

PeterStaev commented May 11, 2017

@NathanaelA , read my previous comment very carefully. I did not say that I'm against having a seed template. I said that IMO its place is not in the CLI. So I'm all for @radeva's idea to create a unified template which others can use to create plugins. But IMO its place is not in the CLI.

As for plugin errors - your whole comment is irrelevant as adding the CLI option will neither magically sanitize existing plugins from their problems, nor will force the creation of future plugins using this option/template. This can easily be handled by adding some plugin developer portion to the plugins site where authors can check if there are any problems with any of their plugins (if it is really that important and could cause problems with usage).

@NathanaelA

This comment has been minimized.

Show comment
Hide comment
@NathanaelA

NathanaelA May 11, 2017

Contributor

I think you must have missed what I said, . I didn't say I wanted my template in the CLI. What I want in the CLI was the ability to install ANY template without TNS mangling it. ;-) The original related issue to this might have been the first time I have ran into it, but it wasn't the last time this mangling has caused issues.

As for plugin errors, I totally disagree; it could easily eliminate a whole class of errors from all new plugins, and simplify the setup for any authors. Right now there is ~400 plugins in the NativeScript eco system. Cordova has ~2200. If my blog, PNR (plugins.nativescript.rocks), PNO (plugins.nativescript.org), and the NS docs, all recommended creating plugins by doing something like: tns create nativescript-somename --template plugin don't you think that by default because the tns-plugin-template handles those issues automatically during creation you eliminate them for the vast majority of the next 1700 plugins.. ;-) Yes, there will be stragglers who do it there own way; but this would allow the majority to have it fixed by default.

This can easily be handled by adding some plugin developer portion to the plugins site where authors can check if there are any problems with any of their plugins (if it is really that important and could cause problems with usage).

[ Deleted the poor wording ] A better way to put this is that I am not paid by anyone for building/maintaining/running the any of the NativeScript.rocks sites, they are a labor of love. So adding new features to PNR is another endeavor using my own time/money, this feature is planned for the future but other PNR features have a much higher priority at this time. In addition I have try to schedule the free community stuff in-between paid stuff so that I can eat and spend family time.

So at this point I personally believe the best solution is to fix TNS so it won't mangle templates and so that we get a consistent plugins created.

Contributor

NathanaelA commented May 11, 2017

I think you must have missed what I said, . I didn't say I wanted my template in the CLI. What I want in the CLI was the ability to install ANY template without TNS mangling it. ;-) The original related issue to this might have been the first time I have ran into it, but it wasn't the last time this mangling has caused issues.

As for plugin errors, I totally disagree; it could easily eliminate a whole class of errors from all new plugins, and simplify the setup for any authors. Right now there is ~400 plugins in the NativeScript eco system. Cordova has ~2200. If my blog, PNR (plugins.nativescript.rocks), PNO (plugins.nativescript.org), and the NS docs, all recommended creating plugins by doing something like: tns create nativescript-somename --template plugin don't you think that by default because the tns-plugin-template handles those issues automatically during creation you eliminate them for the vast majority of the next 1700 plugins.. ;-) Yes, there will be stragglers who do it there own way; but this would allow the majority to have it fixed by default.

This can easily be handled by adding some plugin developer portion to the plugins site where authors can check if there are any problems with any of their plugins (if it is really that important and could cause problems with usage).

[ Deleted the poor wording ] A better way to put this is that I am not paid by anyone for building/maintaining/running the any of the NativeScript.rocks sites, they are a labor of love. So adding new features to PNR is another endeavor using my own time/money, this feature is planned for the future but other PNR features have a much higher priority at this time. In addition I have try to schedule the free community stuff in-between paid stuff so that I can eat and spend family time.

So at this point I personally believe the best solution is to fix TNS so it won't mangle templates and so that we get a consistent plugins created.

@jlooper

This comment has been minimized.

Show comment
Hide comment
@jlooper

jlooper May 11, 2017

I don't think this is the place to hash over who is making money or who spends more time doing what. Let's decide, rather whether the CLI is going to have this functionality: tns create plugin my-awesome-plugin which would pick up an official seed and send the developer off to the races.

@dtopuzov you added the 'up-for-grabs' label. Does that mean you will review a PR to add this functionality?

jlooper commented May 11, 2017

I don't think this is the place to hash over who is making money or who spends more time doing what. Let's decide, rather whether the CLI is going to have this functionality: tns create plugin my-awesome-plugin which would pick up an official seed and send the developer off to the races.

@dtopuzov you added the 'up-for-grabs' label. Does that mean you will review a PR to add this functionality?

@dtopuzov dtopuzov removed the help wanted label May 12, 2017

@dtopuzov

This comment has been minimized.

Show comment
Hide comment
@dtopuzov

dtopuzov May 12, 2017

Member

Removing the label, since there are different votes, for or against this feature.

Member

dtopuzov commented May 12, 2017

Removing the label, since there are different votes, for or against this feature.

@NathanaelA

This comment has been minimized.

Show comment
Hide comment
@NathanaelA

NathanaelA May 12, 2017

Contributor

@jlooper - I apologize for that; I was in a huge rush to pick up my wife from the airport; and didn't really have the time to edit it properly and eliminate the stuff I should have eliminated before posting it. I should have just left it open, rather than hitting the Comment button, and finished when I got home...

Contributor

NathanaelA commented May 12, 2017

@jlooper - I apologize for that; I was in a huge rush to pick up my wife from the airport; and didn't really have the time to edit it properly and eliminate the stuff I should have eliminated before posting it. I should have just left it open, rather than hitting the Comment button, and finished when I got home...

@PeterStaev

This comment has been minimized.

Show comment
Hide comment
@PeterStaev

PeterStaev May 12, 2017

Contributor

@NathanaelA , I think you are overreacting on this one. First of all I meant the OFFICIAL plugins site not the .rocks one.
But whatever, now back on topic: Can you explain what will be the benefit of writing:

tns plugin create nativescript-myplugin --template tsc

Instead of:

git clone https://github.com/NativeScript/tsc-plugin-seed nativescript-myplugin
cd nativescript-myplugin
npm run setup

Because I really do not see any valid argument mentioned thus-far, except the visibility one, which can easily be solved if this is written in the official docs, rocks sites, your blog, etc.

Contributor

PeterStaev commented May 12, 2017

@NathanaelA , I think you are overreacting on this one. First of all I meant the OFFICIAL plugins site not the .rocks one.
But whatever, now back on topic: Can you explain what will be the benefit of writing:

tns plugin create nativescript-myplugin --template tsc

Instead of:

git clone https://github.com/NativeScript/tsc-plugin-seed nativescript-myplugin
cd nativescript-myplugin
npm run setup

Because I really do not see any valid argument mentioned thus-far, except the visibility one, which can easily be solved if this is written in the official docs, rocks sites, your blog, etc.

@atanasovg

This comment has been minimized.

Show comment
Hide comment
@atanasovg

atanasovg May 12, 2017

Member

Thanks all for your valuable input. I really appreciate the passion and obsession to make {N} a better technology in both the team and the community. In this comment I will try to explain the philosophy and understanding that the team have about the CLI and how we should further develop it. Missing publicly visible documentation that describes this philosophy is something that we need to improve and we are after it as of now.

Basically we are fans of the "Keep the core minimalistic and expose flexible extension points" approach. By "minimalistic" we understand only the set of commands that are applicable to the majority (95%+) of our users. Following this approach allows us to be more focused and to do fewer things but with great quality.

If I make an analogy - that would be the core modules and all the 400+ community plugins that extend the core in some way by adding new functionality.

The team also hear community hands-on problems/issues and really understand them. So far the CLI didn't have some flexible way, except the hooks, to do some real extension in terms of new commands and/or modifying default commands' behavior. Because of this we needed to balance between our principles and solving community feature requests. Good news is that this is no longer true. We have recently introduced a new extensibility model in the CLI that allows for really great level of flexibility, including custom commands and consuming CLI internal APIs/data/variables. @rosen-vladimirov can share more details as he is the engineer that put most thought behind this implementation.

That said, having this new model will allow us to keep the CLI core minimal and in the same time will give means to the community to extend it the way they need. Plus, any other user that needs some custom functionality will be able to simply install the NPM package containing the command(s) and to take advantage of them directly within the CLI.

@NathanaelA Considering the new model (we are still to document it), do you think that creating a new command by yourself, without the need to make a PR to the core, will suffice your needs? You will be able to promote such custom commands much like plugins.

Member

atanasovg commented May 12, 2017

Thanks all for your valuable input. I really appreciate the passion and obsession to make {N} a better technology in both the team and the community. In this comment I will try to explain the philosophy and understanding that the team have about the CLI and how we should further develop it. Missing publicly visible documentation that describes this philosophy is something that we need to improve and we are after it as of now.

Basically we are fans of the "Keep the core minimalistic and expose flexible extension points" approach. By "minimalistic" we understand only the set of commands that are applicable to the majority (95%+) of our users. Following this approach allows us to be more focused and to do fewer things but with great quality.

If I make an analogy - that would be the core modules and all the 400+ community plugins that extend the core in some way by adding new functionality.

The team also hear community hands-on problems/issues and really understand them. So far the CLI didn't have some flexible way, except the hooks, to do some real extension in terms of new commands and/or modifying default commands' behavior. Because of this we needed to balance between our principles and solving community feature requests. Good news is that this is no longer true. We have recently introduced a new extensibility model in the CLI that allows for really great level of flexibility, including custom commands and consuming CLI internal APIs/data/variables. @rosen-vladimirov can share more details as he is the engineer that put most thought behind this implementation.

That said, having this new model will allow us to keep the CLI core minimal and in the same time will give means to the community to extend it the way they need. Plus, any other user that needs some custom functionality will be able to simply install the NPM package containing the command(s) and to take advantage of them directly within the CLI.

@NathanaelA Considering the new model (we are still to document it), do you think that creating a new command by yourself, without the need to make a PR to the core, will suffice your needs? You will be able to promote such custom commands much like plugins.

@NathanaelA

This comment has been minimized.

Show comment
Hide comment
@NathanaelA

NathanaelA May 12, 2017

Contributor

@PeterStaev - Due to a lot of reasons, PNR is way more likely to see these types of changes over PNO. So that is why I responded with PNR and trying to explain that it not a funded project. so even on PNR it is probably not a feature that will show up anytime soon, even though it has been in my long term goals for over a year now.

The difference is the KISS (Keep It Simple Stupid) principle:
1, I don't have to know anything beyond tns help, and it can say tns create plugin xxxxx or tns create xxxxx --template plugin and it is easily found any time anyone needs it.
2. Under your plan I have to find this repo (or the docs linking me to the repo); everytime I want to create a plugin. That is extra work each time I want to create a new plugin, and that assumes there is no confusion over repo names and how easily I can find the docs each time...
3. More steps, means more places for someone to do it wrong. I'm sure you have had those types of bug reports where it is documented, but people still don't do it correctly. Less steps = better & simpler.
4. You are presuming they have git installed, there are lots of people who use svn and hg. ;-)

My goal is to make the initial plugin creation as simple/idiot proof as I can make it. The less gears that are present, the less places something can go wrong. It can be done using your steps (assuming they have git installed), but it is several factors more complicated each time, than my suggested method.


@atanasovg - that sounds decent. Do you know or @rosen-vladimirov if the plugin commands have an api that do things like download, extraction. Or does the cli-plugin have to duplicate all the functionality?

Contributor

NathanaelA commented May 12, 2017

@PeterStaev - Due to a lot of reasons, PNR is way more likely to see these types of changes over PNO. So that is why I responded with PNR and trying to explain that it not a funded project. so even on PNR it is probably not a feature that will show up anytime soon, even though it has been in my long term goals for over a year now.

The difference is the KISS (Keep It Simple Stupid) principle:
1, I don't have to know anything beyond tns help, and it can say tns create plugin xxxxx or tns create xxxxx --template plugin and it is easily found any time anyone needs it.
2. Under your plan I have to find this repo (or the docs linking me to the repo); everytime I want to create a plugin. That is extra work each time I want to create a new plugin, and that assumes there is no confusion over repo names and how easily I can find the docs each time...
3. More steps, means more places for someone to do it wrong. I'm sure you have had those types of bug reports where it is documented, but people still don't do it correctly. Less steps = better & simpler.
4. You are presuming they have git installed, there are lots of people who use svn and hg. ;-)

My goal is to make the initial plugin creation as simple/idiot proof as I can make it. The less gears that are present, the less places something can go wrong. It can be done using your steps (assuming they have git installed), but it is several factors more complicated each time, than my suggested method.


@atanasovg - that sounds decent. Do you know or @rosen-vladimirov if the plugin commands have an api that do things like download, extraction. Or does the cli-plugin have to duplicate all the functionality?

@rosen-vladimirov

This comment has been minimized.

Show comment
Hide comment
@rosen-vladimirov

rosen-vladimirov May 13, 2017

Contributor

Hey @NathanaelA ,
I'm glad to share some more details for the new Extensibility model in CLI. It's still in a very early stage, but we'll be really happy in case you give it a try and share your opinion. The main concept is described in this PR. You can create a real npm package and use NativeScript CLI to install it as extension. Whenever CLI is loaded, it automatically loads all extensions, so they can be used when resolving commands, services, etc. I'll try to give an example - you want to add tns plugin create <name> command. Create a new package (in fact there's no need to publish it in npm, you can install it from .tgz, directory, github repo, etc. In the package, you'll have to use the CLI syntax for registering command - create a new class that has:

  • canExecute method - the definition of the method is: canExecute?(args: string[]): Promise<boolean> - it is called before the real execution of command and the idea is to validate the arguments passed by user. The command will be executed only in case this method returns a Promise that's resolved with a true value.
  • execute method - execute(args: string[]): Promise<void> - it's the heart of the command - the real code execution is here. The method receives the arguments passed by user, so the code can use them.

As NativeScript CLI uses Dependency Injection in order to resolve commands and services, you have to register your class in the global $injector that CLI creates:

$injector.registerCommand("plugin|create", PluginCreateCommand);

NOTE: The pipe ('|') is required when you want command name to have spaces, so when the user writes tns plugin create myAwesomePlugin, and you have registered the command as plugin|create, the args that will be passed to canExecute and execute methods will be [ "myAwesomePlugin" ] only. In case you register your command with $injector.registerCommand("plugin", PluginCreateCommand);, and user writes the same command, you'll receive [ "create", "myAwesomePlugin" ] as args.

Now the only remaining thing is to create an entry point for your plugin. Our idea is the entry point to be just the bootstrap - the place where you tell the $injector in which file it will find the registered modules. So create a bootstrap.js file and add the following line to it:

$injector.requireCommand("plugin|create", <full path to file where the command is located>);

Here is a very simple example, that allows you to execute tns hello-world <name> command.
https://github.com/rosen-vladimirov/ns-extension-hello-world

As per the other question - you are able to access everything that is registered in CLI's bootstrap here and here (CLI uses a submodule, so some of the code is in a separate repository) and call its methods. For example in case you want to execute some http request, you can use the httpClient module registered in CLI:

  1. In your constructor you should add the $httpClient module:
class PluginCreateCommand {
    constructor($httpClient) { this.$httpClient= $httpClient; }

This way, when CLI creates an instance of your class, it will inject the $httpClient module and methods of your class will be able to call methods of the $httpClient module registered in CLI.
2. After that you are able to call the method httpRequest of the $httpClient:

this.$httpClient.httpRequest("https://nativescript.or")
				.then(response => {
					console.log("Body of response is: ", response.body);
				})
				.catch(err => {
					console.error("Err: ", err);
				});

For extraction you can use the unzip method of CLI's $fs module.

Hope this will give you basic idea how you can create an extension. We are still working on some issues (for example how to allow extensions to add help for the newly added commands, how to add new -- options via extension, etc.) and we are trying to document everything. The commands for managing extensions are already documented, you can try tns help extension in order to get some more information. Also you can find information about CLI's dependency injection mechanism here.

Contributor

rosen-vladimirov commented May 13, 2017

Hey @NathanaelA ,
I'm glad to share some more details for the new Extensibility model in CLI. It's still in a very early stage, but we'll be really happy in case you give it a try and share your opinion. The main concept is described in this PR. You can create a real npm package and use NativeScript CLI to install it as extension. Whenever CLI is loaded, it automatically loads all extensions, so they can be used when resolving commands, services, etc. I'll try to give an example - you want to add tns plugin create <name> command. Create a new package (in fact there's no need to publish it in npm, you can install it from .tgz, directory, github repo, etc. In the package, you'll have to use the CLI syntax for registering command - create a new class that has:

  • canExecute method - the definition of the method is: canExecute?(args: string[]): Promise<boolean> - it is called before the real execution of command and the idea is to validate the arguments passed by user. The command will be executed only in case this method returns a Promise that's resolved with a true value.
  • execute method - execute(args: string[]): Promise<void> - it's the heart of the command - the real code execution is here. The method receives the arguments passed by user, so the code can use them.

As NativeScript CLI uses Dependency Injection in order to resolve commands and services, you have to register your class in the global $injector that CLI creates:

$injector.registerCommand("plugin|create", PluginCreateCommand);

NOTE: The pipe ('|') is required when you want command name to have spaces, so when the user writes tns plugin create myAwesomePlugin, and you have registered the command as plugin|create, the args that will be passed to canExecute and execute methods will be [ "myAwesomePlugin" ] only. In case you register your command with $injector.registerCommand("plugin", PluginCreateCommand);, and user writes the same command, you'll receive [ "create", "myAwesomePlugin" ] as args.

Now the only remaining thing is to create an entry point for your plugin. Our idea is the entry point to be just the bootstrap - the place where you tell the $injector in which file it will find the registered modules. So create a bootstrap.js file and add the following line to it:

$injector.requireCommand("plugin|create", <full path to file where the command is located>);

Here is a very simple example, that allows you to execute tns hello-world <name> command.
https://github.com/rosen-vladimirov/ns-extension-hello-world

As per the other question - you are able to access everything that is registered in CLI's bootstrap here and here (CLI uses a submodule, so some of the code is in a separate repository) and call its methods. For example in case you want to execute some http request, you can use the httpClient module registered in CLI:

  1. In your constructor you should add the $httpClient module:
class PluginCreateCommand {
    constructor($httpClient) { this.$httpClient= $httpClient; }

This way, when CLI creates an instance of your class, it will inject the $httpClient module and methods of your class will be able to call methods of the $httpClient module registered in CLI.
2. After that you are able to call the method httpRequest of the $httpClient:

this.$httpClient.httpRequest("https://nativescript.or")
				.then(response => {
					console.log("Body of response is: ", response.body);
				})
				.catch(err => {
					console.error("Err: ", err);
				});

For extraction you can use the unzip method of CLI's $fs module.

Hope this will give you basic idea how you can create an extension. We are still working on some issues (for example how to allow extensions to add help for the newly added commands, how to add new -- options via extension, etc.) and we are trying to document everything. The commands for managing extensions are already documented, you can try tns help extension in order to get some more information. Also you can find information about CLI's dependency injection mechanism here.

@rosen-vladimirov

This comment has been minimized.

Show comment
Hide comment
@rosen-vladimirov

rosen-vladimirov Aug 23, 2018

Contributor

Related PRs: #3800
#3836

This feature is available in CLI's next version. You can give it a try and send your feedback!

Contributor

rosen-vladimirov commented Aug 23, 2018

Related PRs: #3800
#3836

This feature is available in CLI's next version. You can give it a try and send your feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment