emberjs / ember-dev Goto Github PK

Any objections to this? It appears that http://github.com/emberjs/website, http://github.com/emberjs/data, http://github.com/emberjs/ember.js all do this already, but not this project.

The last couple of Travis builds have errored due to issues with git tag --points-at not working properly.

My guess is that this is related to their recent updates, but I will investigate further.

I've just tried creating a project that uses ember-dev and when I start the rack server I get this error message:

NameError: uninitialized constant Ember::Source

It is referring to this line in server.rb:

 [200, {'Content-Type' => 'text/javascript'}, [File.read(::Ember::Source.bundled_path_for("ember.js"))]]

I'm not sure where the Ember module is supposed to be coming from, I've tried including the ember-source in my gem file:

gem 'ember-source', path: '../ember.js'

But still no dice.

Where is the Ember module supposed to be coming from?

So the README says it not ready for public use, but to get in touch if you want to help out. I would be happy to write a blog post, README, or both. I've been working on a little ember library (an extension to ember table) and would love to learn the right way to package it up. It seems like this is it? So anyways, consider this me volunteering :)

Similar to expectDeprecation, a handler for checking that the right Ember.warn happened during a test will lead to stronger tests and therefore an even stronger codebase.

See http://stackoverflow.com/questions/2969967/confirm-existance-of-executable-script-bat-cmd-exe-via-a-ruby-file

I'm using ember-dev as the build tool for tastypie-adapter (https://github.com/pedrokiefer/ember-data-tastypie-adapter/tree/ember-data-1.0-beta), but I had to manually add a copy of ember-data.js to /dist directory or the tests wouldn't run.

The way ember is loaded on the template file works perfectly, maybe the same should be applied to ember-data after 1.0 release.

See #47.

We need to update our release rake tasks to handle the various actions needed for branching from master to beta.

The tasks to be performed are:

• Merge master into beta (git checkout beta && git merge master)
• Update the VERSION file.
• Run rake ember:prepare (runs :changelog and :bump_version tasks).
• Run rake ember:deploy (runs :commit, :tag, and :push tasks).

@wagenet - Could you review this list of tasks to ensure that it is complete? What am I missing?

Otherwise we get no stack :(

I'm working on an addon that will be introducing some deprecations. I would like to test that a deprecation warning was raised. @mixonic suggested to use expectDeprecation but I haven't been able to get this library injected into my addon's test environment.

I tried installing this library as an addon and added the following to my test-helper.js

import Ember from 'ember';
import setupQUnit from 'ember-dev/test-helper/setup-qunit';
import EmberDevTestHelperAssert from 'ember-dev/test-helper/index';

var testHelpers = new EmberDevTestHelperAssert(Ember, false);
setupQUnit(testHelpers);

I expect to get expectDeprecation in my tests, but it doesn't look like it's available.

How do I get this working?

Currently, we require it to be installed globally (which is not a good idea).

Using ignoreDeprecation only applies to synchronous code. In talking with @mixonic he suggested that one way to handle this is to allow the function parameter passed in to be optional. If called without the function, deprecations would just be ignored to the end of the test run.

I'm thinking this should be the default if there's no features.json present. I'll put in a PR if yall agree.

Related: #158

These assertions are valuable for addon development to facilitate changing APIs, but are also useful for coordinating changes in apps with large teams. Ideally, these helpers would be included in a build tree as part of a cli addon, making them directly importable in tests, e.g.

// tests/integration/post-list.js
import hbs from 'htmlbars-inline-precompile';
import { describeComponent, it } from 'ember-mocha';
import { expectDeprecation } from 'ember-dev-mocha';

describeComponent('post-list', 'PostListComponent', { integration: true }, function() {
  it("should trigger a deprecation when specifying the `sortBy` attr", function() {
    expectDeprecation(() => {
      this.render(hbs`
        {{#post-list sortBy="nope"}}
      `);
    }, /The `sortBy` attribute is deprecated, pass in a sorted list instead./);
  });
});

Questions:

• Should this project be the target addon for all test frameworks, or should it act like ember-test-helpers and be designed for framework-specific addons to consume?
• If the later, what should the external assertion API look like? Is a single boolean assertion adequate, or should it support multiple assertion types?
• Should this project be de-addon-ified (supplying a /lib dir like ember-test-helpers)
• Should separate addons be created (e.g. ember-dev-qunit/ember-dev-mocha), or should support be added directly to ember-mocha and ember-qunit?
• If the later, is it safe to use chai style expect(...).to.be assertions?

cc @mixonic @mmun @rwjblue @dgeb

This occurs due to the refactoring done in emberjs/ember.js#3752 to store the location in the container.

not sure what the best way in rake is, presumedly something like

if `which defeatureify` == "defeatureify not found" do
  `npm install -g defeatureify`
end

Ember repositories have always included a test/index.html to run the test suite.

With the introduction of ember-dev, this test environment has been removed in both repositories ( ember.js and data ). Right now, i am missing:

• debugging with web inspectors and other tools
• being able to run an independent test

IMO, this feature should be included.

Just wanted to gauge if anyone is interested in this. I can probably put it together pretty easily, and that would allow us to access the assets for JSFiddle/JSBin demos within the comments of various pull requests.

The structure could look like:

/pr/<project name>/<pr number>/<files>

We would be able to use enviroment variables from Travis to know the various pieces (see here for details).

I'm more than happy to do this if you think it would be beneficial.

QUnit.ok is not longer a function... (maybe more compat issues)

This is based on a conversation with @wycats in #emberjs-dev.

@wycats - Is this still something you want to see happen?

This addon has some good stuff in it. Being able to know that your application hit no deprecations, warnings, or asserts during testing is actually pretty cool. But just poking around it doesn't seem like a lot of people are using this. Maybe because they don't know about it or maybe there is a simpler way to do that?

This library could use a little modernizing ... e.g. it doesn't support QUnit 2. I'd be happy to investigate this if others would find value in it. Then again, maybe ember-test-helpers and ember-qunit would be a better place for those asserts. Any thoughts?

Tests only pass with 1.8.