Avoid having to install @componizer/schematics as a dev dependency in the project

[chihab]

That would be great if we save the developer from having to install the schematics.

The only way to achieve that AFAICT:

• Not using schematics🙃. We would use something like copy-template-dir as a dependency to the extension and bundle everything before packaging the extension.
• Bundling the schematics, putting the bundle inside the extension package (~5MB) and invoking it directly from there (setting up a relative path to the schematics), that should work as long as we provide an entry factory function.

Any other suggestion?

[chihab]

I wonder if invoking a script using npx @componizer/run-schematics that would npx ng g @componizer/schematics inside the project would work?

[bilelmsekni]

Indeed, removing the schematics was one of the enhancements we have been looking for. To do that, I prefer the second option (bundeling the schematics with the extension) but to get there, the schematics needs to depend on schematics and not the ng-cli-schematics.
I don't really like the npx solution as I'm not sure which version of the componizer schematics will be run. It should be the same as the one specified by the extension

[bilelmsekni]

Also, don't forget that we thrive to make the extension framework agnostic while the schematic is framework free. for example, we will use the same extension but we can have two schematics, one for Angular and the other for React :)

[chihab]

the schematics needs to depend on schematics and not the ng-cli-schematics.

You mean the "..extension depend on schematics..." here right? Is there a way to use schematics as a lib without the cli?

Regarding the npx solution, I think that would be the same as today because today we have to install the package manually and we're never sure that the installed package is in sync with the extension version. But I guess that is something we'd like to improve also.

[bilelmsekni]

If you look at the code of the schematics, it starts by calling the standard component schematics (ng generate component) then builds upon it. That's what I meant by schematics depends on the cli schematics. A nice improvement will be to integrate our schematics with ng add like NG material or NGRX when you do ng add material, it does everything for the user,
I think it will be nice to have ng add compnizer to avoid having the user installing the dependency by himself

This requires is simple tweak in the schematics json file as far as I remember, if you are up to the challenge

[chihab]

That would be cool if the user does really nothing: the README would be just about installing the extension.

What if we check, either on installation or when the user clicks on "Componize", that the schematics dependency is present and if so we execute it, and if not we install it (maybe after user confirmation) and then execute it.

Now about the installation, we have two choices, either we add it to devDependencies (via ng-add) or we just install it without adding it. I would opt for not adding it to package.json, I find weird that an application has to depend on a dependency used by an external tool (vscode here).

What do you think Bilel?

[bilelmsekni]

I agree with you, adding the schematics to devdependencies doesn't make sense. It will be nice if we can find some other way
If you look at the changelog in the unreleased section:

Changelog

It's the first item on the list ^^