Code Monkey home page Code Monkey logo

ember-cli-shims's Introduction

Ember CLI Shims

Greenkeeper badge

Note: this project is deprecated. If you are using these shims in your project you should migrate to the new modules api outlined in RFC 176 as soon as you can. More information on this topic in the Ember 2.16 release blog post.

Note that you won't be able to drop this dependency from your app's package.json file until all your addons have upgraded to ember-cli-babel >= 6.6.0.

About

Ember CLI Shims (ECS) contain all the shims used in Ember CLI.

Note: The ember-data shim has been removed as of v0.1.0. The latest Ember-Data no longer has a bower dependency; ember-cli-shims >= v0.1.0 is only intended for use with Ember-Data v2.3.0 and up.

Usage

Simply import any of the shims as an ES6 module:

import Component from 'ember-component';
import run from 'ember-runloop';
import injectService from 'ember-service/inject';

Some of the shims have named exports (instead of/in addition to a default export):

import { assert, copy } from 'ember-metal/utils';
import { debounce } from 'ember-runloop';
import { isEmpty } from 'ember-utils';

Shims

The app-shims file provides a complete reference of all modules currently supported by this library.

Why?

Historically, Ember has recommended that developers reference core classes & utilities (ie Component, Route, isEmpty) via the root Ember namespace. This leads to the entire Ember module being imported into nearly every file:

import Ember from 'ember';

export default Ember.Component.extend({
  foo: Ember.inject.service(),
  bar: Ember.computed.readOnly('foo.bar')
});

It would be preferable to have different parts of Ember available as separate modules, allowing developers to only import what they need. This is the direction the framework is moving in, but the modules are not yet available. This has led to a common pattern of ES6 destructuring assignment to enable writing future-proof code:

import Ember from 'ember';

const { Component, computed, inject } = Ember;

export default Component.extend({
  foo: inject.service(),
  bar: computed.readOnly('foo.bar');
});

However, this library provides shims to mimic the future modules that Ember may provide, enabling developers to avoid destructuring and instead import the namespaces as modules today.

import Component from 'ember-component';
import computed from 'ember-computed';
import injectService from 'ember-service/inject';

export default Component.extend({
  foo: injectService(),
  bar: computed.readOnly('foo.bar');
});

That way, as true modules become available in the Ember ecosystem, we can merely remove the shims from ECS upstream, requiring little to no refactoring on the part of developers who have opted-in to this pattern early. Ultimately, the goal of this library is to be replaced completely once Ember itself is an npm package/addon and exports its own modules.

License

Ember CLI Shims is MIT Licensed.

ember-cli-shims's People

Contributors

amk221 avatar bantic avatar cbroeren avatar chriskrycho avatar cibernox avatar daltones avatar dhaulagiri avatar duggiefresh avatar ef4 avatar elwayman02 avatar fsmanuel avatar greenkeeper[bot] avatar hankfanchiu avatar jayphelps avatar locks avatar marten-dockyard avatar mitchlloyd avatar rwjblue avatar stefanpenner avatar thorsteinsson avatar tomdale avatar tricknotes avatar turbo87 avatar twokul avatar wagenet avatar xiphiasuvella avatar zeppelin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ember-cli-shims's Issues

Ember Build failing with 1.x versions

Hello.. unfortunately my build is failing with the 1.0.2 version. Ember 2.9.1

The Broccoli Plugin: [SourceMapConcat: Concat: Vendor /assets/vendor.js] failed with:
Error: ENOENT: no such file or directory, stat 'Y:\xyz\tmp\source_map_concat-input_base_path-QEfGWDfe.tmp\0\bower_components\ember-cli-shims\app-shims.js'
    at Error (native)
    at Object.fs.statSync (fs.js:987:18)
    at FSMonitor._measure (Y:\xyz\node_modules\heimdalljs-fs-monitor\index.js:66:21)
    at Object.statSync (Y:\xyz\node_modules\heimdalljs-fs-monitor\index.js:82:30)
    at Concat.keyForFile (Y:\xyz\node_modules\broccoli-caching-writer\index.js:87:20)
    at Array.map (native)
    at Concat.CachingWriter._conditionalBuild (Y:\xyz\node_modules\broccoli-caching-writer\index.js:109:65)
    at Y:\xyz\node_modules\broccoli-caching-writer\node_modules\broccoli-plugin\read_compat.js:61:34
    at tryCatch (Y:\xyz\node_modules\rsvp\dist\rsvp.js:538:12)
    at invokeCallback (Y:\xyz\node_modules\rsvp\dist\rsvp.js:553:13)

The broccoli plugin was instantiated at: 
    at Concat.Plugin (Y:\xyz\node_modules\broccoli-caching-writer\node_modules\broccoli-plugin\index.js:10:31)
    at Concat.CachingWriter [as constructor] (Y:\xyz\node_modules\broccoli-caching-writer\index.js:18:10)
    at new Concat (Y:\xyz\node_modules\broccoli-concat\concat.js:32:17)
    at module.exports (Y:\xyz\node_modules\broccoli-concat\index.js:26:10)
    at EmberApp.concatFiles (Y:\xyz\node_modules\ember-cli\lib\broccoli\ember-app.js:370:10)
    at EmberApp._concatFiles (Y:\xyz\node_modules\ember-cli\lib\broccoli\ember-app.js:383:15)
    at EmberApp.javascript (Y:\xyz\node_modules\ember-cli\lib\broccoli\ember-app.js:1269:12)
    at EmberApp.toArray (Y:\xyz\node_modules\ember-cli\lib\broccoli\ember-app.js:1640:10)
    at EmberApp.toTree (Y:\xyz\node_modules\ember-cli\lib\broccoli\ember-app.js:1662:30)
    at module.exports (Y:\xyz\ember-cli-build.js:41:16)

Build failed.

does anyone have an idea about this?
cheers
Daniel

An in-range update of loader.js is breaking the build 🚨

Version 4.5.0 of loader.js just got published.

Branch Build failing 🚨
Dependency loader.js
Current Version 4.4.1
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As loader.js is β€œonly” a devDependency of this project it might not break production or downstream projects, but β€œonly” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this πŸ’ͺ

Status Details
  • ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 7 commits.

  • 094e20b release v4.5.0 πŸŽ‰
  • db2f6a6 Merge pull request #126 from ember-cli/moduleId
  • 204838b rename mod.name => mod.id
  • 4fa0fe0 add require.moduleId to allow a module to know its ID
  • f62bc54 Merge pull request #121 from ember-cli/define-exports
  • d963886 Update README.md
  • 928e18f add define.exports

See the full diff

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

Release update

The tests fix added by #18 has not been released yet. Ember CLI's reference to "ember-cli-shims": "ember-cli/ember-cli-shims#0.0.3" pulls down the previous version of test-shims.js. This breaks ember-cli-mocha because the code in test-shims.js is trying to define QUnit when it doesn't exist.

Please release v0.0.4 so we can update Ember CLI's bower.json accordingly.

In the interim I will use master branch instead of a release.

Disable TravisCI

It appears that TravisCI is enabled for this repo but there is actually no .travis.yml file present. Since there are currently no tests it would probably make sense to disable TravisCI for this repo until that is the case. Otherwise PRs will be flagged as "failing" all the time because of the missing .travis.yml file.

Why is isArray called isEmberArray

isEmberArray makes it sound like a plain array needs to be an Ember Array, but the tests for isArray say otherwise?

isEmberArray(Ember.A()); // true, great makes sense
isEmberArray([]); // true, expecting false 

An in-range update of ember-cli-inject-live-reload is breaking the build 🚨

The devDependency ember-cli-inject-live-reload was updated from 1.8.2 to 1.10.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

ember-cli-inject-live-reload is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 9 commits.

  • 60b2ba2 1.10.0
  • 415935b Add yarn.lock.
  • 542a2a0 Migrate to lerna-changelog + add 1.10.0 to changelog.
  • a21fd1d Merge pull request #55 from SparshithNR/path-fix
  • f6d8238 Provide backward compatibility.
  • ab29353 Pass path as argument to livereload.js
  • 68c237e release v1.9.0 πŸŽ‰
  • 2e88996 Merge pull request #54 from SparshithNR/test-refactor
  • fcd41eb Refactoring and Tests

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Ember.merge is depreciated as of Ember-cli 2.5.0

I believe I have tracked down a depreciation warning to the app-shims.js using Ember.merge here:

 'ember-platform': {
    'assign':         Ember.merge,
    'create':         Ember.create,
    'defineProperty': Ember.platform.defineProperty,
    'hasAccessors':   Ember.platform.hasPropertyAccessors,
    'keys':           Ember.keys
  },

According to this it seems like a simple change.

Export Ember.testing?

Although it might not be the best practice, I found myself importing all Ember in an addon just to get Ember.testing.

Should it be exported? If not, is there a better "official" way of detecting when we are in test mode?

An in-range update of loader.js is breaking the build 🚨

Version 4.2.0 of loader.js just got published.

Branch Build failing 🚨
Dependency loader.js
Current Version 4.1.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As loader.js is β€œonly” a devDependency of this project it might not break production or downstream projects, but β€œonly” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this πŸ’ͺ


Status Details
  • ❌ continuous-integration/travis-ci/push The Travis CI build failed Details
Commits

The new version differs by 14 commits .

  • cc53069 release v4.2.0
  • 1a453d3 Merge pull request #104 from trentmwillis/redefine
  • 93478ef Improve redefinition scenarios
  • e289916 Fix test:dev command
  • 287a487 Merge pull request #105 from trentmwillis/clarify
  • cda1c29 Clarify prime comment
  • 562ecf1 Merge pull request #100 from jrowlingson/master
  • 6a9b916 remove petal references
  • b609262 Merge pull request #95 from chadhietala/heimdall-instrumentation
  • c49296d Instrument with heimdall
  • 453fe8c Merge pull request #97 from Turbo87/ci-deploy
  • 37fef79 CI: Enable automatic NPM deployment for tags
  • c4f0755 Merge pull request #96 from chadhietala/dict-registry
  • 8a34296 Use dict for registery and seen to avoid filling IC cache

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

#54 introduces behavior difference depending on Ember version

In #54, a shim was added for ember-platform/assign which will use Ember.assign if available (β‰₯ 2.5.0) and Ember.merge otherwise. These do not have the same method footprint/behavior so could be a concern.

Ember.assign({}, {foo: 3}, {bar: 5})
// -> Object {foo: 3, bar: 5}

Ember.merge({}, {foo: 3}, {bar: 5})
// -> Object {foo: 3}

An in-range update of ember-cli-htmlbars-inline-precompile is breaking the build 🚨

The devDependency ember-cli-htmlbars-inline-precompile was updated from 1.0.3 to 1.0.4.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

ember-cli-htmlbars-inline-precompile is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Could not find module `ember-data`

I don't think this is a bug with ember-cli-shims, but I spent a bit of time learning that if I stick with ember-cli-shims 0.6.0 the problem disappears.

I am making this issue in case it helps anyone else in a similar situation to narrow down the variables.

Uncaught Error: Could not find module `ember-data` imported from `active-model-adapter/active-model-adapter`

ember 1.13.13
ember-cli 1.13.15
ember-cli-shims 1.0.0
ember-data 1.13.16
active-model-adapter 2.0.3

reverting to ember-cli-shims 0.6.0 seems to resolve this issue for me.

Generate an easy to read list of all shims included from the source

While the code is obviously not made for this, it was a fun exercise to extract a markdown compatible listing of all the shims from this addon. I'm pretty sure this is a rather brutal way, but it works.

I haven't figured on the best way to do it, but this could easily be part of the publishing process of this addon to have a proper reference.

function handlerFactory(path = '') {
	return {
		get(target, name) {
			return name in target? target[name] : `${path}.${name.toString()}`;
		},
	}
}

function mapEntries(obj, cb) {
	return Object.entries(obj).map(cb);
}

const obj = {};

function listEmberCliShims() {
	global.Ember = new Proxy([
		'inject',
		'Instrumentation',
		'platform',
		'run',
		'String',
		'computed',
		'Test',
	].reduce((acc, key) => {
		acc[key] = new Proxy({ _key: `Ember.${key}` }, handlerFactory(`Ember.${key}`));

		return acc;
	}, { _key: 'Ember' }), handlerFactory('Ember'));

	const defined = {};

	global.define = (name, [], cb) => {
		const val = cb();

		if (val.default && val.default._key) {
			val.default = val.default._key;
		}

		defined[name] = val;
	};

	global.self = {
		jQuery: 'self.jQuery',
	};

	require('ember-cli-shims/vendor/ember-cli-shims/app-shims');

	return defined;
}

function listEmberCliShimsAsMarkdown(shims) {
	return `# All shims provided by this addon

${mapEntries(shims, ([key, value]) =>
`## \`${key}\`

${mapEntries(value, ([k, v]) =>
`- \`${k}\` ${(v || '').toString()}`).join("\n")}



`
	).join('')}`;
}

console.log(listEmberCliShimsAsMarkdown(listEmberCliShims()));

Results via node generate.js > results.md

All shims provided by this addon

ember

  • default Ember

ember-application

  • default Ember.Application

ember-array

  • default Ember.Array

ember-array/mutable

  • default Ember.MutableArray

ember-array/utils

  • A Ember.A
  • isEmberArray Ember.isArray
  • wrap Ember.makeArray

ember-component

  • default Ember.Component

ember-components/checkbox

  • default Ember.Checkbox

ember-components/text-area

  • default Ember.TextArea

ember-components/text-field

  • default Ember.TextField

ember-controller

  • default Ember.Controller

ember-controller/inject

  • default Ember.inject.controller

ember-controller/proxy

  • default Ember.ArrayProxy

ember-controllers/sortable

  • default Ember.SortableMixin

ember-debug

  • log Ember.debug
  • inspect Ember.inspect
  • run Ember.runInDebug
  • warn Ember.warn

ember-debug/container-debug-adapter

  • default Ember.ContainerDebugAdapter

ember-debug/data-adapter

  • default Ember.DataAdapter

ember-deprecations

  • deprecate Ember.deprecate
  • deprecateFunc Ember.deprecateFunc

ember-enumerable

  • default Ember.Enumerable

ember-evented

  • default Ember.Evented

ember-evented/on

  • default Ember.on

ember-globals-resolver

  • default Ember.DefaultResolver

ember-helper

  • default Ember.Helper
  • helper

ember-instrumentation

  • instrument Ember.Instrumentation.instrument
  • reset Ember.Instrumentation.reset
  • subscribe Ember.Instrumentation.subscribe
  • unsubscribe Ember.Instrumentation.unsubscribe

ember-locations/hash

  • default Ember.HashLocation

ember-locations/history

  • default Ember.HistoryLocation

ember-locations/none

  • default Ember.NoneLocation

ember-map

  • default Ember.Map
  • withDefault Ember.MapWithDefault

ember-metal/destroy

  • default Ember.destroy

ember-metal/events

  • addListener Ember.addListener
  • removeListener Ember.removeListener
  • send Ember.sendEvent

ember-metal/get

  • default Ember.get
  • getProperties Ember.getProperties

ember-metal/mixin

  • default Ember.Mixin

ember-metal/observer

  • default Ember.observer
  • addObserver Ember.addObserver
  • removeObserver Ember.removeObserver

ember-metal/on-load

  • default Ember.onLoad
  • run Ember.runLoadHooks

ember-metal/set

  • default Ember.set
  • setProperties Ember.setProperties
  • trySet Ember.trySet

ember-metal/utils

  • aliasMethod Ember.aliasMethod
  • assert Ember.assert
  • cacheFor Ember.cacheFor
  • copy Ember.copy
  • guidFor Ember.guidFor

ember-object

  • default Ember.Object

ember-owner/get

  • default Ember.getOwner

ember-owner/set

  • default Ember.setOwner

ember-platform

  • assign Ember.assign
  • create Ember.create
  • defineProperty Ember.platform.defineProperty
  • hasAccessors Ember.platform.hasPropertyAccessors
  • keys Ember.keys

ember-route

  • default Ember.Route

ember-router

  • default Ember.Router

ember-runloop

  • default Ember.run
  • begin Ember.run.begin
  • bind Ember.run.bind
  • cancel Ember.run.cancel
  • debounce Ember.run.debounce
  • end Ember.run.end
  • join Ember.run.join
  • later Ember.run.later
  • next Ember.run.next
  • once Ember.run.once
  • schedule Ember.run.schedule
  • scheduleOnce Ember.run.scheduleOnce
  • throttle Ember.run.throttle

ember-service

  • default Ember.Service

ember-service/inject

  • default Ember.inject.service

ember-set/ordered

  • default Ember.OrderedSet

ember-string

  • camelize Ember.String.camelize
  • capitalize Ember.String.capitalize
  • classify Ember.String.classify
  • dasherize Ember.String.dasherize
  • decamelize Ember.String.decamelize
  • fmt Ember.String.fmt
  • htmlSafe Ember.String.htmlSafe
  • loc Ember.String.loc
  • underscore Ember.String.underscore
  • w Ember.String.w

ember-utils

  • isBlank Ember.isBlank
  • isEmpty Ember.isEmpty
  • isNone Ember.isNone
  • isPresent Ember.isPresent
  • tryInvoke Ember.tryInvoke
  • typeOf Ember.typeOf

ember-computed

  • default Ember.computed
  • empty Ember.computed.empty
  • notEmpty Ember.computed.notEmpty
  • none Ember.computed.none
  • not Ember.computed.not
  • bool Ember.computed.bool
  • match Ember.computed.match
  • equal Ember.computed.equal
  • gt Ember.computed.gt
  • gte Ember.computed.gte
  • lt Ember.computed.lt
  • lte Ember.computed.lte
  • alias Ember.computed.alias
  • oneWay Ember.computed.oneWay
  • reads Ember.computed.reads
  • readOnly Ember.computed.readOnly
  • deprecatingAlias Ember.computed.deprecatingAlias
  • and Ember.computed.and
  • or Ember.computed.or
  • collect Ember.computed.collect
  • sum Ember.computed.sum
  • min Ember.computed.min
  • max Ember.computed.max
  • map Ember.computed.map
  • sort Ember.computed.sort
  • setDiff Ember.computed.setDiff
  • mapBy Ember.computed.mapBy
  • mapProperty Ember.computed.mapProperty
  • filter Ember.computed.filter
  • filterBy Ember.computed.filterBy
  • filterProperty Ember.computed.filterProperty
  • uniq Ember.computed.uniq
  • union Ember.computed.union
  • intersect Ember.computed.intersect

ember-test

  • default Ember.Test

ember-test/adapter

  • default Ember.Test.Adapter

ember-test/qunit-adapter

  • default Ember.Test.QUnitAdapter

jquery

  • default self.jQuery

rsvp

  • default Ember.RSVP

What part of the shim blocks svg:use + example

I was at a meetup last night ~ and mentioned my issues with SVG - and waiting for Ember 2.7 for the removal of baseURL (which is supposedly blocking svg:use) – and someone said that when they remove ember-cli-shims that the SVGs show up again.

What part of the shims affect this?

To reproduce, one could

  1. drop this markup into a fresh application.hbs
  2. serve + view
  3. stop
  4. remove ember-cli-shims
  5. serve + view
{{!-- icon styles --}}
<style>
[class^="icon-"], [class*=" icon-"] {
    height: 32px;
    width: 32px;
    display: inline-block; 
    fill: currentColor;
    border: 1px solid red;
}
</style>

{{!-- the svg (hidden) --}}
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">

  <symbol id="icon-smile" viewBox="0 0 512 512">
    <path d="m361 307c-7 23-21 42-40 56c-19 14-41 21-65 21c-24 0-46-7-65-21c-19-14-33-33-40-56c-1-5-1-9 2-14c2-4 5-7 10-9c5-1 10-1 14 1c5 3 8 6 9 11c5 16 14 28 27 37c13 10 27 14 43 14c16 0 30-4 43-14c13-9 22-21 27-37c1-5 4-8 9-11c4-2 9-2 14-1c5 2 8 5 10 9c3 5 3 9 2 14z m-142-124c0 10-3 19-10 26c-7 7-16 10-26 10c-10 0-19-3-26-10c-7-7-11-16-11-26c0-10 4-19 11-26c7-7 16-11 26-11c10 0 19 4 26 11c7 7 10 16 10 26z m147 0c0 10-4 19-11 26c-7 7-16 10-26 10c-10 0-19-3-26-10c-7-7-10-16-10-26c0-10 3-19 10-26c7-7 16-11 26-11c10 0 19 4 26 11c7 7 11 16 11 26z m73 73c0-25-5-48-15-71c-9-23-22-42-39-58c-16-17-35-30-58-39c-23-10-46-15-71-15c-25 0-48 5-71 15c-23 9-42 22-58 39c-17 16-30 35-39 58c-10 23-15 46-15 71c0 25 5 48 15 71c9 23 22 42 39 58c16 17 35 30 58 39c23 10 46 15 71 15c25 0 48-5 71-15c23-9 42-22 58-39c17-16 30-35 39-58c10-23 15-46 15-71z m36 0c0 40-9 77-29 110c-20 34-46 60-80 80c-33 20-70 29-110 29c-40 0-77-9-110-29c-34-20-60-46-80-80c-20-33-29-70-29-110c0-40 9-77 29-110c20-34 46-60 80-80c33-20 70-29 110-29c40 0 77 9 110 29c34 20 60 46 80 80c20 33 29 70 29 110z"/>
  </symbol>

</svg>

{{!-- in use use --}}
<svg class="icon-x"><use xlink:href="#icon-smile"></use></svg>

Missing isEqual

I am wondering why the isEqual method is not available when using import { isEqual } from 'ember-runtime';.
Is there any other way to import it or should I import the entire Ember module first?

An in-range update of ember-ajax is breaking the build 🚨

Version 2.5.4 of ember-ajax just got published.

Branch Build failing 🚨
Dependency ember-ajax
Current Version 2.5.3
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As ember-ajax is β€œonly” a devDependency of this project it might not break production or downstream projects, but β€œonly” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this πŸ’ͺ


Status Details
  • ❌ continuous-integration/travis-ci/push The Travis CI build failed Details
Release Notes v2.5.4

Changelog

  • Ensure that requestData has the correct method and type (#231)

Note: This release was not cut from master, which contains breaking changes in preparation for v3.0.0

Commits

The new version differs by 2 commits .

  • 3798d33 2.5.4
  • 5d98a44 Ensure that requestData has the correct method and type (#231)

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

Ember.RSVP Export

Ember.RSVP is a large hole in this package's exports. ember-rsvp seems like an obvious package name, though the fact that we have forked RSVP itself and re-exported it also lends the possibility that we should pick a different name altogether.

@rwjblue had some more thoughts on this, I believe.

An in-range update of ember-cli-version-checker is breaking the build 🚨

Version 1.3.0 of ember-cli-version-checker just got published.

Branch Build failing 🚨
Dependency ember-cli-version-checker
Current Version 1.2.0
Type dependency

This version is covered by your current version range and after updating it in your project the build failed.

ember-cli-version-checker is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this πŸ’ͺ

Status Details - ❌ **continuous-integration/travis-ci/push** The Travis CI build failed [Details](https://travis-ci.org/ember-cli/ember-cli-shims/builds/224959236)

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

New module syntax and deprecations with addons

Lots of addons still use the old syntax. We need a way to be able to support both without deprecations. What is the current recommendation for this? We will want addons to use the new modules, while supporting older Ember versions as well.

An in-range update of silent-error is breaking the build 🚨

The dependency silent-error was updated from 1.1.0 to 1.1.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

silent-error is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

Commits

The new version differs by 3 commits.

  • fcf21cb release v1.1.1 πŸŽ‰
  • 290cc4a Merge pull request #2 from warmans/master
  • aed9cab Added LICENSE file.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of ember-cli-dependency-checker is breaking the build 🚨

Version 2.0.1 of ember-cli-dependency-checker just got published.

Branch Build failing 🚨
Dependency ember-cli-dependency-checker
Current Version 2.0.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As ember-cli-dependency-checker is β€œonly” a devDependency of this project it might not break production or downstream projects, but β€œonly” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this πŸ’ͺ

Status Details
  • ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

Commits

The new version differs by 3 commits.

  • fa28114 v2.0.1
  • 8c5a979 Merge pull request #77 from kanongil/resolved-check
  • bca8aa5 Also check shrinkwrap version against "_resolved" field. Fixes #76

See the full diff

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

Ember.Test missing as well.

when registering a test helper you use,

export default Ember.Test.registerAsyncHelper

I'm assuming that will need to be exported as well. Didn't see it in the rfc list either.

[BUG] ember-cli-shims 0.0.6 and above is not compatible with Node

Using ember-cli-shims version of 0.0.6 and above in Fastboot (Node) environments gives an error:
self is not defined

This prevents the vendor file to be loaded in the sandbox. The error seems to be coming https://github.com/ember-cli/ember-cli-shims/blob/master/app-shims.js#L247 where it is using self.jQuery. While this would work in browsers, self is not defined in Node environments.

We should check for existence of self before assigning the jQuery module.

I propose something like:

var jQueryVersion;
if (self) {
  jQueryVersion = self.jQuery;
} else {
 jQueryVersion = jQuery;
}
generateModule('jquery', { 'default': jQueryVersion });

Bower dependencies causing ember 2.0 issues

The bower.json file for this project lists the dependency

  "dependencies": {
    "ember": ">=1.4"
  }

This creates an issue once you upgrade to ember 2.0.0: executing bower install on your CI server results in bower forcing you to make a choice (due to incompatible versions) so your CI builds fail.

The resulting output of bower install is:

Unable to find a suitable version for ember, please choose one:
    1) ember#>=1.4 <2 which resolved to 1.13.8 and is required by ember-cli-shims#0.0.3, ember-load-initializers#0.1.5
    2) ember#> 1.5.0-beta.3 which resolved to 1.13.8 and is required by ember-resolver#0.1.18
    3) ember#2.0.0 which resolved to 2.0.0 and is required by crawler-ui
    4) ember#^2.0.0 which resolved to 2.0.0 and is required by ember-data#2.0.0-beta.2

Prefix the choice with ! to persist it to bower.json

Persisting your choice to the bower.json file is a valid work around for this issue, but it probably should not be required.

Incorrect AMD Module Definitions

I have a Webpack module with a UMD loader front-end that has an external jQuery as a dependency. Due to this line in this module, jQuery is not passed to the AMD factory function properly and I get errors in my application. This also only happens when define.amd is true which is what happens when using this feature introduced into Ember v2.9.0. Here's an explanation for why this is happening.

Webpack's UMD loader looks like this (in my application that requires an external jQuery)

(function webpackUniversalModuleDefinition(root, factory) {
	if(typeof exports === 'object' && typeof module === 'object')
		module.exports = factory(require("jquery"));
	else if(typeof define === 'function' && define.amd)
		define(["jquery"], factory);
	else if(typeof exports === 'object')
		exports["mySubModule"] = factory(require("jquery"));
	else
		root["myApp"] = root["myApp"] || {}, root["myApp"]["mySubModule"] = factory(root["jQuery"]);
})

which in the case of Ember, where there is only an AMD loader (also dependent on using the feature described above which defines define.amd) boils down to define(["jquery"], factory);. As generated by webpack, the factory is supposed to be passed the jQuery module as per the RequireJS AMD docs. To quote their docs for the loading process (emphasis mine)...

  • Register the factory function by calling define(), instead of immediately executing it.
  • Pass dependencies as an array of string values, do not grab globals.
  • Only execute the factory function once all the dependencies have been loaded and executed.
  • Pass the dependent modules as arguments to the factory function.

The problem is that with this module, it defines jQuery as an ES6 module. When the factory function is called, it is passed an object that looks like...

{
    __esModule : true,
    default : $
}

...which is not equivalent to the jQuery library. I would have to do $["default"] to get jQuery. If an AMD loader is not present, then webpack works just fine as the last UMD loader line will get jQuery off of window no problem.

My thoughts, from reading the RequireJS docs, is that Ember is not correctly passing jQuery. But if you think this is a webpack issue I can take this over there.

Concerns over this library

I have some serious concerns about this library, if its intention is to be the path forward and representative of what Ember will be like when it is modularized. We are discussing its use over destructuring internally at DockYard. Here is where I am currently landing:

Ember's own project organization

This library exposes an issue I have with Ember's organization. It doesn't feel intuitive and is not simple to find things. I'm sure those who work on and contribute to Ember on a regular basis will disagree but for someone who has been working with Ember for over four years and has made contributions back to core several times I can honestly say I have no idea where anything is, ever. It ends up being a guessing game every time. Up until now that has been little more than an annoyance. But if Ember's structure is going to be exposed through the module system this annoyance is significantly magnified.

Documentation

Part of the way people learn is through discovery. They see a demo and say "Ok, I need to import ember-metal/get but I'd like to learn more, let me look up the documentation" and they're treated with http://emberjs.com/api/modules/ember-metal.html which isn't very helpful.

This is even better illustrated with the modules defined in this shim that don't exist at all. ember-array or ember-object for example.

Why modules over paths?

This issue was brought up over a year ago when the module style for all the packages was originally proposed. I am still confused as to why core prefers ember-object over ember/object. I thought things landed on @stefanpenner proposing the use of @ember/object. I cannot recall which project this was discussed in, otherwise I would link to the issue.

Getting DS is not defined

I'm getting this error from ember-cli-shims/app-shims.js:

Uncaught ReferenceError: DS is not defined
    at eval (eval at evaluate (unknown source), <anonymous>:1:1)
    at Object.InjectedScript._evaluateOn (<anonymous>:895:55)
    at Object.InjectedScript._evaluateAndWrap (<anonymous>:828:34)
    at Object.InjectedScript.evaluateOnCallFrame (<anonymous>:954:21)
    at http://localhost:4200/agent/assets/vendor.js:67613:3
    at mod.state (http://localhost:4200/agent/assets/vendor.js:150:29)
    at tryFinally (http://localhost:4200/agent/assets/vendor.js:30:14)
    at requireModule (http://localhost:4200/agent/assets/vendor.js:148:5)
    at requireFrom (http://localhost:4200/agent/assets/vendor.js:121:12)
    at reify (http://localhost:4200/agent/assets/vendor.js:106:22)

I'm on Ember 1.13.2, and Ember Data 1.13.4, and Ember CLI 0.2.7.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.