Local storage has stopped working

No, I do not use github for this. I put all the relevant code in the description. What else do you need to know. As I said the code has worked for some time until the infrastructure was updated.

The only things which might be missing are the app_module:
import { IonicStorageModule } from ‘@ionic/storage’;
IonicStorageModule.forRoot({name:’__name’, driverOrder: [‘indexeddb’, ‘sqlite’, ‘websql’]}),

and the service:
import { Storage } from ‘@ionic/storage’;
public http: HttpClient,
public network: Network,
public appConfig: AppConfigService,
private storage: Storage
) { }

I have re-enabled the storage by going back to version 2.2.0 of @ionic/storage, the problem seems to be with the new noop code in version 2.3.0.

I had to examine the code to find the likely problem and then try it. This took me about 2 days of effort that I can ill afford.

How should we adapt our code to make this work on the latest version? Shouldn’t updates include instructions if the code needs changing - this is what I get with linux.

Does anyone have any advice on how to make @ionic/storage 2.3.0 work??

I asked for a sample project that could be used to inspect this.
Please provide one.

I have tested 2.3.0 of storage and it’s working fine for me.

As you probably discovered figuring this part out, that triggers if window.process is defined. So is there a possibility that you’ve got some dependent library in your project that is defining it? If so, can you eliminate that dependency? If not, can you try undefining it? First place I would attempt to do so would be in main.ts right before bootstrapping the app.

I did a search for window.process within the whole of my app directory using the Find in Files… facility in Gedit. The only files that this appears are in node-modules. Most of these are part of a useColors function, exceptions are the isInBrowser function in support-map-support.js, and the resolve function in resolve.js. All of these are part of ‘if’ statements so should not be setting anything.

What code can I use to undefine window.process?

Is there any other way it can be set?

I would expect the following to work:

delete (window as any).process;

I used the following in my main.ts to replicate your problem:

(window as any).process = {};

  .catch(err => console.log(err));

Combining that with this simple page:

export class HomePage {
  n = 0;

  constructor(private storage: Storage) {

  bump(): void {
      .then(() => this.storage.get("n"))
      .then(n => n + 1)
      .then(n => this.storage.set("n", n))
      .then(() => this.storage.get("n"))
      .then(n => this.n = n);
    <ion-label>n is {{n}}</ion-label>
  <ion-button (click)="bump()">bump</ion-button>

…and I see your symptoms: n becomes blank on the first click of the “bump” button, and never recovers.

All of that being said, the code you have posted is still problematic, and I would urge you to rearchitect it. The primary issue here is that storage writes are not synchronous. I can think of two ways around this: one is to meticulously wait on the promises returned by every set call. That is a massive PITA in my book, and also causes needless performance hiccups.

A better approach, I think, is to use storage only to communicate between app runs, not within one. So only read from storage once, at app startup, or whenever the information is first needed. Write whenever you like. For in-app communication, use mutually injected service providers to share data, not storage.


I tried your fix but it didn’t change anything. I also tried a test app, which worked. I have also searched for the pattern within my app directory without success. So I am sticking with version 2.2.0 for now until I can determine what the root cause actually is.

Actually, the storage is primarily used for user information that enables them to automatically logon to the server where the bulk of the information and processing is. There is a service in-place for exchanging data between pages and the design minimises that information exchange.

With the fault, I have revisited the storage code such that at first access the object is stored as part of the service so the storage is only used at the start when read and when the objects change - which is rarely. The primary setting point is user login.

If you cannot replicate the issue in a new project, it’s not going to be possible to debug. If you end up being able to replicate and can provide a sample project, please do.

On my failing app I managed to look at the value of the process. I have a screen shot but it will not let me upload; I have tried png and jpg without success (from linux). The process object is filled with a bunch of NOOP elements and has been produced by the browser.js function (node-modules.process.browser.js). So the process is undefined, it is just filled with NOOPs. The function suggested to clear the process doesn’t work. I cannot figure out what is calling the browser.js function or why it is being called. There are a number of modules that incorporate it, e.g. www/vendor-es.js. I use mermaid.js within my app, this does incorporate the browser.js function but I have included it in my test app and it has no impact on the process. Why is storage bothered about the process?

Please just provide a demo app that has the same issue. I do not need you to look into further, I can manage that. I need you to provide an example that has the issue you’ve mentioned.

It’s treating the presence of a defined process global as an answer to the question “am I running under Angular server-side rendering?”.

It might help me make a less-pathological repro if you could post the entire package.json from your affected project.

I have the same problem and very much appreciate this discovery about window.process. Well, it turns out that you have to define it if you want to use the AWS Amplify, as told to us by this documentation:

More specifically, this is the relevant code that the AWS Amplify library wants us to add as part of the setup, to src/polyfills.js:

(window as any).global = window;
(window as any).process = {
  env: { DEBUG: undefined },

I’ll look into whether i can “eliminate that dependency”, but I’m not sure. In the meantime, I think I can easily create a repro so will try that first.

1 Like

Brilliant! That’s exactly the sort of non-pathological example I was looking for. I would advise you to temporarily pin @ionic/storage at 2.2.0 in your package.json and watch the discussion on this commit, because I suspect the endgame here is for Ionic to change the way it attempts to detect SSR. I came across the SO thread that kygoh posted as a comment there during my detective endeavour here, and it does indeed strike me as a more robust method.

Thanks for the suggestion to roll back one version to 2.2.0. Before reading your suggestion, I did end up reproducing the problem in a minimal app here:

Unfortunately, going to version 2.2.0 did not solve this issue, as you can see in the reproduced repository above, which I’ve updated to go back to version 2.2.0 of @ionic/storage, but which still shows the same issue reported here. To see the issue in action:

  • Run the app in the repo above and check the DEV console - you’ll see result = undefined in DEV console.
  • Now comment out the line that sets window.process in src/polyfills.js and you’ll see result = test-value

The place in the code that prints out result = .. is in app.component.ts.

Not really, I don’t think. Try ~2.2.0, not ^2.2.0.

1 Like

Oops, that’s right, I just tested the reproduction with the “real” version 2.2.0 (which was not there before, since I had ^2.2.0 as you mention @rapropos) - and there is no issue with version 2.2.0 – all works as it did before. I will now go back to version 2.3.0 in the reproduced repository, in order to demonstrate that the issue exists with the latest version 2.3.0.

I do not want to expose the workings of my app as that poses a security risk. So I first tried recreating the essentials of my app using a new base app but I couldn’t get that to fail.

I then tried reducing my app to the essential components so that I could release it. I then tried moving it to a new base app to reflect what you might do with it. Unfortunately, it now worked properly so useless for testing. I then created a new base app and copied my app to it and it worked properly. This was odd as the first thing I did when the app first failed was to remove the node-modules and re-install them but this didn’t work.

I have tried looking at the differences between the working and non-work app with version 2.3.0. There is no difference in the src data. There is a small difference between to configuration elements. However, most difference is between the node-modules even though they are supposed to be all at the same version. So I don’t know what is causing the problem.

The different process running when the app doesn’t work is browser.js. This cannot be found when the app works. So what is requesting this?

All of this is being served within a Chromium browser on debian testing (linux).

@ptuson please note: I have also encountered the issue you report here. I have replicated it in the repository (please read the thread above). rapropos above has already found a workaround solution - go back to version ~2.2.0 of @ionic/storage in your package.json (see thread above). Have you seen your problem continue with that version? If not, then you have a temporary fix, until, in future versions of @ionic/storage this issue will be fixed - all you have to do is go back one version for that package for things to work for you.