1

Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.

I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: @nativescript/schematics).

Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).

Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.

What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.

I have done some research in the topic, but I was unable to find a conclusive answer:

  • the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
  • other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
  • third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
  • lastly, for some odd reason, the @nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts

While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.

In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.

ArtOfCode
  • 5,702
  • 5
  • 37
  • 56
SPArcheon
  • 1,273
  • 1
  • 19
  • 36

2 Answers2

1

Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.

But of course, you may write your own schematics if you like immediate support for environment files.

Manoj
  • 21,753
  • 3
  • 20
  • 41
  • thanks for the suggestion, but then a question remains - why the schematics creates environment.ts and environment.prod.ts? – SPArcheon Oct 19 '18 at 07:09
  • I presume it's for the web app. Schematics are still at early stage, you may raise this as a feature request in the repo. – Manoj Oct 19 '18 at 12:36
0

I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of @types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!

Yevgeniy Shapiro
  • 21
  • 2
  • yep, I know about the Webpack options. The problem is that I don't think that setting can be used to switch between different "environments". Will have to check, I think the last version of Nativescript may have some improvements in this field – SPArcheon Nov 13 '18 at 08:19
  • Sorry if I am stating the obvious, but just to clarify - the Webpack build setting is required if you have a shared web/mobile project, since it's during the webpack bundling process the nativescript specific files that have .tns. in their names are getting bundled properly replacing their web specific counterparts. Did you try to create environment.tns.ts and environment.prod.tns.ts? I bet the webpack bundling process will use them properly during native builds. If this works and you need to do it often, you can change schematics to generate these files automatically for you – Yevgeniy Shapiro Nov 14 '18 at 02:14