When I run ember serve while logging out the environment variable in config/environment.js, I see three values logged:
undefined
development
test
(This is in an inherited project.)
In a fresh app created using ember new my-app, I see three values also:
development
test
development
Which leads me to believe my inherited project is running in test mode and a fresh project is running in development mode as I would expect.
Running ember serve --environment=development does not change the observed behavior in the inherited project.
My questions are why do I see three values logged when running ember serve and how can I figure out why my development environment is running in test?
Whatever calls project.config(environment) is what dictates the environment argument in the config function. If anything calls this function without an argument then you'll see undefined.
As for determining why it's running in test mode, I'd try throwing a debugger statement in your editor (if possible) then see what's calling it with "test". If that's not possible then try printing a call stack somewhere in the function:
module.exports = function(environment) {
...
console.log('current environment: ', environment);
console.log(new Error().stack);
}
You'll see something like:
CURRENT ENVIRONMENT: development
Error
at module.exports (.../config/environment.js:73:15)
at Project.configWithoutCache (.../node_modules/ember-cli/lib/models/project.js:273:47)
at Project.config (.../node_modules/ember-cli/lib/models/project.js:257:21)
at Watcher.module.exports [as serveURL] (.../node_modules/ember-cli/lib/utilities/get-serve-url.js:6:24)
at Watcher.didChange (.../node_modules/ember-cli/lib/models/watcher.js:51:40)
at Watcher.emit (events.js:187:15)
at Watcher.triggerChange (.../node_modules/ember-cli-broccoli-sane-watcher/index.js:174:8)
at tryCatcher (.../node_modules/ember-cli/node_modules/rsvp/dist/rsvp.js:323:19)
at invokeCallback (.../node_modules/ember-cli/node_modules/rsvp/dist/rsvp.js:495:31)
at publish (.../node_modules/ember-cli/node_modules/rsvp/dist/rsvp.js:481:7)
at flush (.../node_modules/ember-cli/node_modules/rsvp/dist/rsvp.js:2402:5)
at process._tickCallback (internal/process/next_tick.js:61:11)
where you can work your way back to see what's setting the environment (in this case it's ember-cli).
Related
I am having problems using Jest manual mocks (the one in a parallel __mocks__ directory) in my project.
I think I understand how to use it and it actually works fine if I remove a single line in a file specified in the Jest setupFiles array.
In that file a global helper is installed (into global.createComp) that uses the vuex store.
This is a vue + vuex project but even running the stripped down spec using only jest gives unexpected results.
Can somebody look at my minimal reproducible example repo at https://github.com/thenoseman/jest-manual-mock-not-working, do a npm i and npm run test:unit and help me understand why the mock is not active?
You can find the line that need to be commented out in test/unit/support/helpers.js.
Also the README shows a screenshot and further explains what the problem looks like.
setupFiles are evaluated before test files. As the reference states,
A list of paths to modules that run some code to configure or set up the testing environment. Each setupFile will be run once per test file. Since every test runs in its own environment, these scripts will be executed in the testing environment immediately before executing the test code itself.
JavaScript modules are evaluated once on first import. Importing #/store/modules/internetAtHome in helpers.js results in importing original #/api/DslService.
The mock in test file doesn't affect #/api/DslService because it has already been evaluated earlier:
jest.mock("#/api/DslService");
import DslService from "#/api/DslService";
In case helpers.js needs mocked #/api/DslService, jest.mock needs to be moved there.
In case helpers.js needs original #/api/DslService but tests need mocked one, the module (and any module that depends on it) needs to be re-imported with jest.resetModules or jest.isolatedModules:
jest.mock('#/api/DslService');
let DslService;
jest.isolateModules(() => {
DslService = require("#/api/DslService").default;
});
...
For a module that was imported with original implementation and needs to be re-imported as a mock, jest.requireMock can be used, it doesn't need jest.mock('#/api/DslService'):
let DslService = jest.requireMock("#/api/DslService").default;
...
I Was testing EmberJs application with Qunit and karma runner and it was working all good.
Then I had to integrate faye into the application which went well but then on running my test suite, it shows following error and crashes:
ReferenceError: Faye is not defined
The error is thrown where, I am defining the client in emberjs
client = new Faye.Client(uri);
Though this works in development, staging but not in testing.
Overhere, uri = "http://localhost:9292/faye"
faye.js is included in vendor.js(single js file which have all the js plugins including ember.js and ember-data.js itself) which is loaded before app.js(file where above line exists)
The reason of that weird behavior is related to the following lines in Faye:
if (typeof module !== 'undefined')
module.exports = Faye;
else if (typeof window !== 'undefined')
window.Faye = Faye;
Source: https://github.com/faye/faye/blob/master/javascript/faye.js#L143
So if module is not undefined(meaning it is defined) then module.exports will be set object, if not, window.Faye will be set.
If you use a debugger and set a breakpoint on that line you will that module is actually defined, why? it is a QUnit global helper method!
Why Faye does this? I guess because it can be run in a NodeJS environment (you can read more about module.exports here).
As I see it you have 2 possible solutions:
Require Faye before QUnit.
Patch Faye to ignore the existence of module in window.
I've encountered the same behavior while using Teaspoon with QUnit.
Making Teaspoon require Faye before QUnit seems like a bad idea and will be probably in ugly hack.
I've ended up with patching Faye to make it skip the module check, not so beautiful either, but I believe this is reasonable.
I am using ember-cli and have a problem with selecting the production environment. Specifically, everything works when I run ember serve --environment=development and I get a blank page when I run ember serve --environment=production. In the console, I see:
Uncaught TypeError: undefined is not a function
Uncaught Error: Could not find module simple-auth/authenticators/base
All other things are equal, and all dependencies are up to date. I'm a total noob so I don't even know where to begin on how to debug: is it ember? ember-cli? broccoli? Any help would be appreciated.
I had exact the same problem, and James_1x0 is correct, it is an broccoli issue.
After debugging it occurs, that the "undefined" error apears on "Ember.handlebars.compile" which lead to other research.
It seems, that in production envrironment "handlebars.js" is replaced by "handlebars.runtime.js" in the ember-cli build process, which seem to be a problem for broccoli at this time.
Other devs had the same problem but with other libraries as well:
https://github.com/stefanpenner/ember-cli/pull/675#issuecomment-47431195
Here the solution was to add:
var index = app.legacyFilesToAppend.indexOf('bower_components/handlebars/handlebars.runtime.js');
if(index) {
app.legacyFilesToAppend[index] = 'bower_components/handlebars/handlebars.js';
}
into your Brocfile.js to replace the "handlebars.runtime.js" with the "handlebars.js".
This also fixed the problem for me.
It sure has the drawback that the whole handlebars file is deployed but its a workarround for now, until the problem is fixed.
Solution is mentioned on Ember CLI website:
This is somewhat non-standard and discouraged, but suppose that due to a requirement in your application that you need to use the full version of Handlebars even in the production environment.
Basically, you can pass vendorFiles option to your EmberApp instance which will force CLI to include full version of Handlebars.
Example of explicitly requiring handlebars.js , in Brocfile.js:
var app = new EmberApp({
vendorFiles: {
'handlebars.js': {
production: 'bower_components/handlebars/handlebars.js'
}
}
});
This is recommended way of solving this issue(discussion on GitHub).
I am running the latest version of Codeception on a WAMP platform - My acceptance is very basic however works fine (see below):
$I = new WebGuy($scenario);
$I->wantTo('Log in to the website');
$I->amOnPage('/auth/login');
$I->fillField('identity','admin#admin.com');
$I->fillField('password','password');
$I->click('Login');
In a nutshell - it checks the page is 'auth/login' fills out 2 form fields and clicks the login button. This works without any problems.
Here is my identical functional test:
$I = new TestGuy($scenario);
$I->wantTo('perform actions and see result');
$I->amOnPage('/auth/login');
$I->fillField('identity','admin#admin.com');
$I->fillField('password','password');
$I->click('Login');
When I run this from the command line I get the following error (not the full error but enough to understand the problem):
1) Couldn't <-[35;1mperform actions and see result<-
[0m in <-[37;1LoginCept.php<-[0m <-41;37mRuntimeException:
Call to undefined method TestGuy::amOnPage<-[0m.......
My Acceptance suite has 'PhpBrowser' & 'WebHelper' modules enabled, the Functional suite has 'FileSystem' & 'TestHelper' enabled (within the acceptance.suite.yml & functional.suite.yml files)
Obviously the amOnPage() function is the problem - however I am led to believe amOnPage() should work in acceptance and functional test? Or I am wrong - also - can someone explain what the numbers mean e.g '<-[35;1m' that appear
UPDATE: I tried adding the 'WebHelper' module to the functional.suite.yml but I do not see the amOnPage() being auto-generated in the TestGuy.php file - any ideas?
My config files are below:
WebGuy
class_name: WebGuy
modules:
enabled:
- PhpBrowser
- WebHelper
config:
PhpBrowser:
url: 'http://v3.localhost/'
TestGuy
class_name: TestGuy
modules:
enabled: [Filesystem, TestHelper, WebHelper]
Well, this is so, because of TestGuy don't have those methods. All of those methods are in the PhpBrowser, Selenium2 modules or other that inherits from Codeception Mink implementation. So you need to add PhpBrowser in your functional suite in modules section, and then run codecept build command.
Also note that it is better to use Selenium2 module for acceptance test and PhpBrowser for functional tests. The main idea is that acceptance(Selenium2) tests must cover those part of your application, that can not be covered by functional (PhpBrowser) tests, for example some js-interactions.
About '<-[35;1m' start script codecept run --no-colors to remove '<-[35;1m' from console output
Here's the fiddle. Here's the gist with the contents of my local file.
As you can see, the HTML and JavaScript are identical, and I'm loading identical versions of the jQuery, Handlebars.js, and Ember.js libraries. It works as expected locally, but does not render the application template on jsFiddle.net.
I see the following error in the Web Console:
[19:44:18.202] Error: assertion failed: You must pass at least an object and event name to Ember.addListener # https://github.com/downloads/emberjs/ember.js/ember-latest.js:51
BTW-To test the gist as a local HTML file, make sure to run it behind a web server or your browser won't download the JavaScript libs. If you have thin installed (ruby webserver), go to the directory it's in and run thin -A file start, then navigate to localhost:3000/jsfiddle-problem.html in your browser.
If you set the "Code Wrap" configuration on your fiddle to one of the options other than "onLoad" your application will work. Here is an example.
The reason for this is Ember initializes an application when the jQuery ready event fires (assuming you have not set Ember.Application.autoinit to false). With the jsFiddle "Code Wrap" configuration set to "onLoad" your application is introduced to the document after the jQuery ready event has fired, and consequently after Ember auto-initializes.
See the snippet below from ember-latest, taken on the day of this writing, which documents Ember auto-initialization being performed in a handler function passed to $().ready.
if (this.autoinit) {
var self = this;
this.$().ready(function() {
if (self.isDestroyed || self.isInitialized) return;
self.initialize();
});
}
This was strange - I couldn't get your fiddle working, specifically your {{controller.foo}} call until I disabled autoinit. I am guessing when using jsfiddle the application initialize kicks off before seeing your router. I also noticed with your fiddle the router was not logging any output even when you had enableLogging set to true.
I updated your fiddle to not use autoinit, http://jsfiddle.net/zS5uu/4/. I know a new version of ember-latest was released today, I wonder if anything about initialization changed.