Environment proposal

[danbucholtz]

I am thinking we could do this:

1. Introduce a new flag that gets passed in like this:

ionic serve --env qa or ionic run android --env prod

My first thought was that it's value would default to dev for non-prod builds, and prod for prod builds. Developer's can pass in whatever they want, though.

2. Based on the value that is passed in (or inferred), the config section of the package.json is read. It could look something like this:

...

"config": {
   "ionic_env" : {
       "dev" : {
          "keyToReplace" : "devValueToReplaceWith",
          "keyTwoToReplace" : "devValueTwoToReplaceWith"
       },
       "qa" : {
          "keyToReplace" : "qaValueToReplaceWith",
          "keyTwoToReplace" : "qaValueTwoToReplaceWith"
       }
   }
},
...

If the ionic_env data is not there, we would just move on in the build process. If it is present, we would then perform the text replacement.

3. Any computed values, sync or async, could be replaced after the build is done. We could either leave this up to the user to add on to the npm script section, or we could provide a hook into the postprocess step. I prefer the latter as it's easier to document and and we can probably make it a 1/2 second faster or so if we do it in app-scripts.

Feedback is appreciated.

Thanks,
Dan

[fiznool]

Looks interesting! I have a few questions.

Any computed values, sync or async, could be replaced after the build is done.

Could you expand on this? I didn't quite understand what you mean.

How would the app use these variables, what would the code look like?

One of the comments in another thread mentioned keeping sensitive values out of source control. Could there be a way of reading in a value from a process.env variable to satisfy this requirement?

[rolandjitsu]

@danbucholtz this looks great. Angular CLI has a similar implementation.

They have a --target which you can use to tell the CLI to either do a production build (AOT, minification, gzip, etc.) or a dev build. Then there's the --environment flag which we can use to choose the appropriate environment.

I'd disagree with the ionic_env working as proposed though. As you also pointed out, there might be a case when we need to compute some values, and that'd be difficult for some users to figure out. How about the following ionic_env:

"ionic_env": {
    "prod": "config/env.prod.js",
    "staging": "config/env.staging.js",
    "dev": "config/env.dev.js"
}

And each file would export the following:

const somePackage = require('somePackage');

module.exports = {
    SOME_VAR: somePackage.getSomeValueSync(),
    SOME_ASYNC_VAL: async function getSomeValueAsync() => {
        await asyncValue = somePackage.computeSomeValueAsync();
        return asyncValue;
    },
    VALUE_FROM_PROCESS: process.env.SOME_ENV_VAR_VAL
};

Then @ionic/app-scripts would require the appropriate env based on the config from ionic_env and for each key it will:

• check if the value is primitive and use that if so
• or if it's a function it would invoke and
  • check if the return value is primitive and use it if so
  • if it's a Promise or an Observable, wait until it's resolved or emits and return that
• then after it successfully computed each value, it would replace where necessary

Perhaps there could be a better approach, but I thing this would work in most scenarios.

[fiznool]

Perhaps I'm missing something, but what sort of use cases would benefit from async computation of values?

[rolandjitsu]

Reading a file for instance (that's also possible to do sync). Or perhaps you store some keys in an AWS bucket and you'd like to pull those keys when you compile the app. I could think of plenty of use cases.

[fiznool]

Right, I'm with you now. 👍

One approach I've seen in other places is to allow exporting a function as well as an object inside the configuration file. This could simplify the logic from the app-scripts end and allow you to build the config object dynamically, and only return once you are ready.

Something along these lines:

// sync example
const somePackage = require('somePackage');

module.exports = {
  SOME_VAR: somePackage.getSomeValueSync();
  VALUE_FROM_PROCESS: process.env.SOME_ENV_VAR_VAL;
};

// async example
const somePackage = require('somePackage');

module.exports = function() {
  const config = {
    SOME_VAR: somePackage.getSomeValueSync();
    VALUE_FROM_PROCESS: process.env.SOME_ENV_VAR_VAL;
  };
  
  return somePackage.computeSomeValueAsync().then(val => {
    config.SOME_ASYNC_VAL = val;
    return config;
  });
};

app-scripts would then perform the following

• If the export is an object, assume it is the config object and use it.
• If the export is a function, assume it will return a promise. Call it, wait for it to be resolved and use the resolved value as the config object.

This has the benefit that app-scripts doesn't need to enumerate all the keys in the config object (what about nested keys?) and provides the most flexibility in your config script (what if the fetching of a second async value depends upon another one being resolved first?)

[rolandjitsu]

@fiznool true, that'd be much simpler and it would help if a value depends on another one. But the app scripts would still need to enum keys in order to replace, but that's just implementation detail.

[rolandjitsu]

Though I'd actually argue that if we export an object, app scripts could potentially run async tasks in parallel so if we'd have more than one property that evaluates to a promise/observable, it could run all of them at once and complete when all are done (something like a Promise.all([ ... ])/Observable.merge(...)).

Yet, the user could do this as well, but if app scripts would do it, it would spare the user of adding extra implementation.

I guess there are many ways this can be tackled, but the simpler the better.

[fiznool]

The difficulty there though, is that if one async value depended on another, you wouldn't be able to resolve the configuration correctly if app-scripts ran everything in parallel. Better to put the logic in the hands of the user, IMHO.

[ehorodyski]

I like where @rolandjitsu is going, but instead of tying it down to a specific implementation, is there a way you can take the environment path being used from package.json in the ionic_env object, and then alias it, so it's import { <T> } from @ionic/config or import { <T> } from @ionic/env?

I don't know how the Angular library does aliasing so you can do import { HTTP } from '@angular/http', instead of import { HTTP } from 'angular/modules/wherever/it/lives/http', but that's how I'd implement it.

Give the users the ultimate control of building what they want to export from their environment/config files, but provide a way for those paths to be swapped out during building, and I think properly creating a module alias, which I don't know how to do, is the best approach.

[danbucholtz]

If we were to expose a hook and allow the user to load in async values, perhaps we could do something like this:

"config" : {
   "ionic_env" : {
      "dev" : "./scripts/dev.config.js",
      "qa" : "./scripts/qa.config.js",
      "prod" : "./scripts/prod.config.js"
      ... etc ...
   }
}

Those modules could then export a function that returns a Promise. That way it will always be async.

It could work like this:

module.exports = function(ionicEnvironment: string) {
   return readSomeAsyncValue().then((result: string) => {
      return {
         'keyOneToReplace' : 'valueOne',
         'keyTwoToReplace' : result
      }
   });
}

Something like this would work in the vast majority of use cases.

In an application's code, let's say you need to hit a different HTTP service for development and production.

You could write a service like this:

export class MyService {
   construtor(public http: Http){
   }

   makeServiceCall() {
      return this.http.makeRequest('$BACKEND_SERVICE_URL');
   }
}

Your implementation to replace it could look like this:

module.exports = function() {
   return Promise.resolve({
      '$BACKEND_SERVICE_URL' : 'localhost:8080/myService'
   });
}