feat: Allow templates to be full applications #3542
Conversation
rosen-vladimirov
force-pushed
the
vladimirov/templates-v2
branch
from
d050c7d to
a9ee3de
Compare
|
run ci |
2 similar comments
|
run ci |
|
run ci |
lib/services/project-service.ts
Outdated
| this.$logger.trace(`Template version is ${templateVersion}`); | ||
| let destinationDir = ""; | ||
| switch (templateVersion) { | ||
| case constants.TemplateVersions.v2: |
There was a problem hiding this comment.
Because we always defatult to v1 here, maybe will be better that the default case is v2 and above.
case constants.TemplateVersions.v1:
const appDestinationPath = this.$projectData.getAppDirectoryPath(projectDir);
this.$fs.createDirectory(appDestinationPath);
destinationDir = appDestinationPath;
break;
default:
destinationDir = projectDir;
| await this.$npm.uninstall(templatePackageJson.name, { save: true }, projectDir); | ||
| if (templateVersion === constants.TemplateVersions.v2) { |
There was a problem hiding this comment.
if (templateVersion !== constants.TemplateVersions.v2) will allow bumping versions without having to alter code.
There was a problem hiding this comment.
We cannot be sure what will be required in the next versions, so I prefer keeping the strictness here - for v2 do this. In case we decide to use v3 and to make it work in a similar manner , we'll alter the code.
There was a problem hiding this comment.
I find it more likely that v3 will be derived from v2 structure rather than from the one of v1.
|
Maybe we can use semver for templateVersion. Just curious why we chose custom versioning. |
Currently when a project is created the content of the template is placed inside the `app` directory of the newly created project. This leads to some issues when you want to support more complex scenarios, for example it is difficult to add configuration file (like nsconfig.json or webpack.config.js) in the root of the project. The suggested solution to allow templates to be the full application is to check the template from which the application is created. In case the template contains a nativescript key and templateVersion property in it, check its value. In case it is v1, use the old way, i.e. place the content of the template in the app directory of the created project. In case it is v2 place the content of the template at the root of the application. In case it is anything else - throw an error. In case it is missing, use v1 as default. The solution ensures backwards compatiblity with existing templates and allows creating new types of templates.
In case the used template does not have App_Resources, we need to copy them from the default template. Ensure the location of the App_Resources in the default template is calculated correctly based on its templateVersion property.
Add `after-createProject` hook, so template authors will be able to execute different operations based on their requirements. The hook is called at the end of the project creation step. Also remove usage of `$projectData` and use `$projectDataService` in order to ensure correct behavior in long living process
rosen-vladimirov
force-pushed
the
vladimirov/templates-v2
branch
from
a9ee3de to
cd3f6cb
Compare
|
@KristianDD I've used REST API versioning as it seems more suitable for the current case where we do no have a specific logic for patches and minor versions. We have absolutely different logic for the two types of templates. |
Currently when a project is created the content of the template is placed inside the
appdirectory of the newly created project.This leads to some issues when you want to support more complex scenarios, for example it is difficult to add configuration file (like nsconfig.json or webpack.config.js) in the root of the project.
The suggested solution to allow templates to be the full application is to check the template from which the application is created. In case the template contains a nativescript key and templateVersion property in it, check its value.
In case it is v1, use the old way, i.e. place the content of the template in the app directory of the created project.
In case it is v2 place the content of the template at the root of the application.
In case it is anything else - throw an error.
In case it is missing, use v1 as default.
The solution ensures backwards compatiblity with existing templates and allows creating new types of templates.
PR Checklist
Fixes/Implements/Closes #[Issue Number].