Hi, Arno.
I think I have the same problem as you.
I used to develop with "sencha app watc(banned) [development]", and when I went to "sencha app build testing|production", everything stopped working, lot of classes were missing, ...
The case is that, in my opinion, there is something very wrong about developing with "app watc(banned)": it preloads all the framework and a lot of stuff, but when you do a build, Sencha Cmd parses all your code looking for the "requires" and only packages the referenced classes.
I always asked myself how could something like this was working:
Code:
Ext.define('.... blablabla.B', {
requires: 'Bla.blablabla.foo.bar.baz.tons.of.words.A',
statics: {
a: Bla.blablabla.foo.bar.baz.tons.of.words.A
}
...
}) ;
in sencha "app watc(banned)" works perfectly: sencha command detects that you will use that "A" class and before defining B, it is already loaded. I was letting my imagination fly about each code file being parsed by Ext.JS before defining a class -because it is not possible to create the options object with a requires and referenced that same class-; and no, there is no magi(banned)c: "app watc(banned)" is tricking us. In this case I have to require the "A" class in Application (for example), or now I make singletons to autoregister themselves once loaded, like here.
And there is a big flaw in "app watc(banned)": it does not warn about all missing requires. Although it is very useful to rapid develop an application without caring about requires, but be aware that you will have problems later on builds.
The real behaviour is the present in "app build", where you have to require on your classes what you will be using.
So, my recommendation: stay away from "app watc(banned)" unless you are working with Fashion, and run your application in a Tomcat/Jetty/Ngix/whatever using "app build development". The missing requires will pop out as errors or warnings in the console.
P.S.: Please, can someone at Sencha fix the banned words issue?