make it node.js compatible

[ro0gr]

With adapters we should be able to configure page object interactions per different environments. However, there are still some blockers to make page objects work cross-env. The goal of the ticket is to build a path forward for page objects to work in node, and probably other envs like different FWs etc.

@ember/*

There are some of ember packages we do currently depend on, and they don't have standalone packages published.

• "@ember/application/deprecations" - Reimplement deprecate #542
  At the end, it's just a console.warn( wrapped with a convenience method, providing a package name, until version and some other contextual info. I think, we should develop our own in-house util for that.

• "@ember/array" - v2: Drop using of EmberArray in favour of native array #523, remove legacy collection #526
  This is currently used for collections, which can be mostly replaced by native array, but we should also provide implementations for mapBy( andfilterBy(.

• "@ember/debug"

  • assert( - replace with throw? get rid of ember assert #527
  • warn( - is going to be removed with the legacy collection removal. remove legacy collection #526

• "@ember/object" - extract alias utils from "helpers" #510
  We only use get( for alias. We could provide our own version of the get(. However, until you don't use alias, it should not fail, so this is a low priority IMO.

• "@ember/polyfills" - use object spread over the Ember assign( #536
  we use assign( accross the board. I believe, it should be enough to just replace it with an object destruction syntax.

• "@ember/utils" - get rid of ember isPresent( #532
  We use isPresent( in few places. Seems like it should be re-implemented on our side.

"jquery" VS "-jquery"

-jquery is a synthetic module (#1, #2), which is only needed to ensure we use the same instance of jQuery, in case if an app depends on jQuery events. However, when ec-page-object tries to import it in node env, it fails, cause there is no EmberCli build process envolved, and -jquery is not liseted in the package.json.

I think we should isolate -jquery imports in the ember adapters, and use jquery for the rest of the places. So it stays resolvable for node, until Ember specific adapters are used.

• Simplify jquery handling #531 should allow us to import jquery as a regular npm module in node.js environments

Ceibo

seems it does no support node require. Needs some attention.

• allow it to be imported in node.js environments Commonjs support ceibo#21

Test

• A node.js test needed. It should serve a dummy page, page.visit((via a custom Adapter for node.js), and do a smoke test of the page object. Node test #538

[patrickberkeley]

I'm running into needing this. We use ember-cli-page-object in a number of apps and addons. Now we would like to reuse those page objects outside of ember for end-to-end testing with a tool like cypress.io, selenium, bigtest.

Due to the structure of this repo (index.js, package.json, exports, etc.) it's proving difficult to make ember-cli-page object's functions available outside of an ember app.

In addition to the issues listed above in this issue description (decoupling from ember specific dependencies), I'm wondering if it would make sense to split the core functionality for creating and querying page objects into a separate non-ember node package. Then consume that new package in ember-cli-page-object. This is a similar pattern to what ember-cli-mirage did with miragejs I believe, and would allow – and ensure – the core functionality is usable outside of ember.

[ro0gr]

I'm wondering if it would make sense to split the core functionality for creating and querying page objects into a separate non-ember node package.

Yes, definitely! My current intention is to make ec-page-object node.js compatible at the first place. This way, from the node.js user's perspective, the import paths would be ugly, like:

// since we would not do the ember-cli pipeline tricks with the import paths
import { clickable } from 'ember-cli-page-object/addon-test-support';

After that, when all the internals are ready, we can extract the core into a framework independent package with the minimal changes, and provide better import paths for the end user of the core.