Open ro0gr opened 4 years ago
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.
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.
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.
[x] "@ember/application/deprecations" - #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.[x] "@ember/array" - #523, #526 This is currently used for collections, which can be mostly replaced by native array, but we should also provide implementations for
mapBy(
andfilterBy(
.[x] "@ember/debug"
assert(
- replace withthrow
? #527warn(
- is going to be removed with the legacy collection removal. #526[x] "@ember/object" - #510 We only use
get(
foralias
. We could provide our own version of theget(
. However, until you don't usealias
, it should not fail, so this is a low priority IMO.[x] "@ember/polyfills" - #536 we use
assign(
accross the board. I believe, it should be enough to just replace it with an object destruction syntax.[x] "@ember/utils" - #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 usejquery
for the rest of the places. So it stays resolvable for node, until Ember specific adapters are used.jquery
as a regular npm module in node.js environmentsCeibo
seems it does no support node
require
. Needs some attention.Test
page.visit(
(via a custom Adapter for node.js), and do a smoke test of the page object. #538