Feature Request

Description

Enhance the serve-static service to accept a file path to packed webpack assets. The serve-static service leverage the serve-static express server which accepts pre-packed assets directory or a webpack configuration to do the configuration before serving assets. It would be nice to open this up for faster CI on parallel builds to eliminate the need to compile for n builds.

Issue Description

For jest testing of internationalized components, packages have been writing custom jest test setup. This could be provided within the toolkit for quick access.

See setup here.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Issue Description

We have a screenshot that was 0.01% different than the reference screenshot (chrome changed how characters that went into the descender were underlined) so it passed the LocalCompare [1][2] check and no diff screenshot was generated. However, the matchReference [3] assertion failed because the images were not exactly the same. Instead of checking isExactSameImage [4], a check could be made against isWithinMisMatchTolerance [5].

[1] https://github.com/cerner/terra-toolkit/blob/v2.7.0/src/wdio/visualRegressionConf.js#L33
[2] https://github.com/zinserjan/wdio-visual-regression-service/blob/v0.8.0/src/methods/LocalCompare.js#L39
[3] https://github.com/cerner/terra-toolkit/blob/v2.7.0/src/wdio/services/TerraService.js#L40
[4] https://github.com/zinserjan/wdio-visual-regression-service/blob/v0.8.0/src/methods/BaseCompare.js#L39
[5] https://github.com/zinserjan/wdio-visual-regression-service/blob/v0.8.0/src/methods/BaseCompare.js#L37

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

The matchReference assertion should not fail for a screenshot that is within the misMatchTolerance.

Current Behavior

The matchReference assertion fails.

Issue Description

Create the ability to test different locales within terra-toolkit.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

We will want this to work in combination with parallelization. Since we can't do this in Travis (you have to pay), and we want to limit resources, we will want the parallelization to be handled via running a very specific combination (e.g. pt-BR and small form factor) and then let the build system (e.g. jenkins) handle the parallelization.

Current Behavior

N/A

Issue Description

Documentation was not updated to reflect the newest toolkit changes.

Issue Description

Axe was locked to 2.5.0 to prevent wdio test failures in dependent projects. Once the changes have been made in the dependent projects to handle the latest release with the new accessibility rule of having a landmark defined on a page, we can unlock this dependency.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

Should pull in the latest released version of axe-core (2.6.1 at this time). Dependent projects (terra-core) should not fail during wdio testing.

Issue Description

This application is not dependent on React being present, so we can remove that as a peerDependency from the project.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Issue Description

Adding the ability to take a screenshot with a combination of multiple CSS custom properties applied at once.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

Create the ability to take screenshots of components with multiple CSS custom properties applied at once.

Current Behavior

N/A

Feature Request

Description

With the new bug report and feature request templates, GitHub offers a way to log an issue without using one of those templates by selecting the Open a regular issue link. This will then use the file at .github/ISSUE_TEMPLATE.md

We should update that file to direct people to bug report or feature request templates.

Additional Context / Screenshots

Other projects that use multiple issue templates and also have .github/ISSUE_TEMPLATE.md

• Gitpoint's issue template
• Babel's issue template
• Webpack's issue template

Issue Description

We want to support parallelization in build systems that support it (e.g. a private instance of Jenkins).

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

Since we can't do this in Travis (you have to pay), and we want to limit resources, we will want the parallelization to be handled via running a very specific combination (e.g. pt-BR and small form factor) and then let the build system (e.g. Jenkins) handle the parallelization.

Current Behavior

N/A

Issue Description

Add a Terra.url() helper to load a url and refresh the browser. Currently the terra-core and terra-framework wdio configuration adds a before hook that refreshes the browser. A full refresh is required for SPA, in order to reset the site, however there are instances where test wouldn't not want the site to be reset due to state-management.

If a test step needs to refresh after loading the browser, it should be specified within that test step that needs it. Adding this helper would reduce the need for

before(() => {
    browser.url();
    browser.refresh();
});

to

before(() => Terra.url());

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Issue Description

The WebpackDevService does not support the webpack.config.js devServer entry.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

The webpack.config.js devServer entry is used as a fallback if config.webpackDevServerConfig is not populated.

Current Behavior

The webpack.config.js devServer entry is ignored.

Issue Description

At times, a screenshot comparison will fail, however a snapshot diff is not generated.

What is happening?

In the Terra.matchesScreenshot() method, we use the visual regression service to generate and compare the screenshots.

There are four types of information returned by the visual regression comparison:

1. isExactMatch
2. isWithinMisMatchTolerance
3. isSameDimensions
4. misMatchPercentage

Currently, we use our custom chai assertion to check if the generated screenshot isExactMatch. This should be updated to check if the image isWithinMisMatchTolerance.

Our tests are failing because they are not exact, however it seems the screenshot diff is not generated because our screenshot is likely within this mismatch tolerance.

Issue Description

I'm on Windows but using a Linux Subsystem for my React dev environment. I keep getting some kind of EINVAL -22 error 💣. The screenshot below says aggregate-translations.js but it also complains about other things in that bin folder.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

It should be installed in peace.👍

Current Behavior

N/A

Steps to Reproduce

1. Open terminal 💻
2. Run npm install terra-toolkit --save-dev ⛏
3. Errors out after in the middle of the installation 💣

Environment

• Component Version: 3.2.0
• Browser Name and Version: N/A
• Operating System and version (desktop or mobile): Desktop Windows 10, Linux Subsystem
• Node: v10.0.0
• npm: 5.6.0

Issue Description

Currently we have our selenium/node-chrome image locked to selenium/node-chrome:3.8.1-erbium due to hanging nightwatch and wdio tests. We should investigate the newest releases to see if these issues remain & if so, why the issue is present.

https://github.com/SeleniumHQ/docker-selenium/releases

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

Use latest chrome image.

Issue Description

React 16 no longer adds data-reactroot to the application. This invalidates all tests that rely on that element being present.

From looking at facebook/react#10971, it sounds like the solution is just to specify id's and classnames to attach to for checking screenshots. Given that, we should add an options argument to be passed into the webdriver.io service.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Summary

The server-launcher checks for WEBPACK_CONFIG_PATH and if one is not provided, it will use the default wepack.cong provided in the toolkit.

It would be nice if the people wanting to use their own webpack configuration in the nightwatch-process script did not need to include the WEBPACK_CONFIG_PATH when they provide their own nightwatch configuation which already specified the webpack.config path.

Current Behavior

Currently, to use their own webpack configuation, one has to use the nightwatch-process script, provide their own nightwatch configuration and include the WEBPACK_CONFIG_PATH argument. Since the webpack configuration path needs to be specified in the nightwatch configuration file, it seems redundant.

Issue Description

In terra v1 consumer could specify their nightwatch output directory. Add ability to specify it here https://github.com/cerner/terra-toolkit/blob/master/src/nightwatch/nightwatch.config.js#L52.

Issue Description

Selenium fails to start and the test don't execute. This seems to only be occurring on Windows 10 machines as far as I've tested. Successfully started and ran on colleagues with macbook and on our jenkins server. Most of my team are .NET developers and need windows machines. I've also tried using the Ubuntu Subsystem for Windows feature on win 10 but also get the same error.

I've tried changing some parameters in the docker-compose file without success and tried to resolve it using some findings on Google but haven't had success yet. This is happening not only with my repository, but it is also happening with terra-toolkit as well. I cloned the terra-toolkit repo and tried running WDIO tests and received the same result.

This leads me to believe it' something potentially with the container, or docker on windows.

The error:

ERROR: Error forwarding the new session Empty pool of VM for setup Capabilities {browserName: chrome, handlesAlerts: true, javascriptEnabled: true, locationContextEnabled: true, loggingPrefs: org.openqa.selenium.logging..., requestOrigins: {name: webdriverio, url: http://webdriver.io, version: 4.9.11}, rotatable: true}
chrome
    at new RuntimeError (c:\Development\singlestack\terra-toolkit\node_modules\webdriverio\build\lib\utils\ErrorHandler.js:144:12)
    at Request._callback (c:\Development\singlestack\terra-toolkit\node_modules\webdriverio\build\lib\utils\RequestHandler.js:313:39)
    at Request.self.callback (c:\Development\singlestack\terra-toolkit\node_modules\request\request.js:186:22)
    at emitTwo (events.js:125:13)
    at Request.emit (events.js:213:7)
    at Request.<anonymous> (c:\Development\singlestack\terra-toolkit\node_modules\request\request.js:1163:10)
    at emitOne (events.js:115:13)
    at Request.emit (events.js:210:7)
    at IncomingMessage.<anonymous> (c:\Development\singlestack\terra-toolkit\node_modules\request\request.js:1085:12)
    at Object.onceWrapper (events.js:314:30)
    at emitNone (events.js:110:20)
    at IncomingMessage.emit (events.js:207:7)
    at endReadableNT (_stream_readable.js:1059:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

Selenium should start and execute the tests

Current Behavior

Selenium fails with the error above.

Steps to Reproduce

1. Execute npm run wdio using the docker-compose file provided by terra-toolkit on a windows 10 machine.

Environment

• Component Version: Latest terra-toolkit
• Operating System and version: Windows 10 Enterprise Edition 1703
• Versions of tools:
  ** Docker version 17.12.0-ce, build c97c6d6,
  ** Node version: v8.4.0,
  ** NPM version: 5.3.0.

Error: Cannot find module 'terra-toolkit/config/webpack/webpack.config'
at Function.Module._resolveFilename (module.js:547:15)
at Function.Module._load (module.js:474:25)
at Module.require (module.js:596:17)
at require (internal/module.js:11:18)
at Object. (C:\Project\asp and webpack-latest\develop_iteration8\eWorkBook\CernerEWBWeb\AspAndWebpack\webpack.config.js:5:32)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Module.require (module.js:596:17)
at require (internal/module.js:11:18)
at requireConfig (C:\Project\asp and webpack-latest\develop_iteration8\eWorkBook\CernerEWBWeb\AspAndWebpack\node_modules\webpack\bin\convert-argv.js:97:18)
at C:\Project\asp and webpack-latest\develop_iteration8\eWorkBook\CernerEWBWeb\AspAndWebpack\node_modules\webpack\bin\convert-argv.js:104:17
at Array.forEach ()
at module.exports

Issue Description

The default webpack configuration specifies two postcss plugins, one for autoprefixer and another for rtl, with autoprefixer executing first. However, this results in some mangled style output:

Current (Autoprefixer -> RTL):

Switched (RTL -> Autoprefixer):

Notice in the Current image that "-webkit-transform: translateZ(0)" doesn't get the [dir] tag. This causes a problem with other SlidePanel styles that are appropriately [dir] wrapped and take precedent inappropriately:

We would still expect the '-webkit-transform: translateZ(0)' style to be applied here, but it's not happening due to the split selector.

There has been some discussion within the postcss project itself that indicates that autoprefixer should rarely be the first executed plugin: postcss/postcss#764. However, we would need to do a little more investigation before just flipping the order.

Shoutout to @dkschoonover for actually debugging this.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Steps to Reproduce

1. Visit the slide panel examples: http://engineering.cerner.com/terra-framework/#/site/components/slide-panel/index
2. Inspect the 'SlidePanel - Position - Start' example.
3. Disable the 'transform: translateZ(0)' style and view panel close. It should fall back to the -webkit-transform style and remain open.

Environment

• Component Version: Current
• Browser Name and Version: Any
• Operating System and version (desktop or mobile): Any

Issue Description

Travis should fail when there are source changes and the change log isn't updated. It should have failed on #42 and did not.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

[email protected] was release to change permissions to 755 on the executable scripts in src/scripts. The solution was to run chmod a+x src/scripts/* to give executable access. When copying files with babel, it will also copy the file permissions. Babel is used in our compile script, so, the read permissions on these src files are the same when compiled to the lib files.

To ensure these permissions remain 755 we should run a check that uses ls -ld src/scripts/* to ensure the file permissions of -rwxr-xr-x is present on the nightwatch.js, nightwatch-process.js and nightwatch-non-parallel.js.

Issue Description

In the current version of css-loader, if you run webpack in production mode, it will minimize the CSS with cssnano v3. The version of cssnano included as a dependency in css loader includes a bug which impacts long-hand CSS properties using CSS custom properties. A fix has supposedly been landed in cssnano v4-rc.2 release (need to test), but that release hasn't made it's way back into css-loader.

We don't see the issue in our default style, the issue is only present when setting values for CSS custom properties that are used in long-hand CSS styles

For example, given the following themable variables:

:root {
    --terra-form-radio-outer-ring-border-style: solid;
    --terra-form-radio-focus-border-color: #88a8ef;
    --terra-form-radio-focus-border-width: 2px;
}

We get output incorrectly as the following from cssnano:

:root {
  border: 2px solid #88a8ef;
}

Attempted fix

We've got around this before by converting the source code to short-hand. This way cssnano doesn't do any conversion on the style.

e.g border: var(--border-style, 1px solid #f00);

Sub issue

However, this causes a problem with styles that could be bidirectional.

For example, we break out padding and margin into individual styles for bidi reasons.

   padding-bottom: var(--terra-tag-padding-bottom, 0.1428rem);
   padding-left: var(--terra-tag-padding-left, 0.5rem);
   padding-right: var(--terra-tag-padding-right, 0.5rem);
   padding-top: var(--terra-tag-padding-top, 0.1428rem);

This seems to make it easier for the postcss-rtl plugin to apply [dir="ltr"] and [dir="rtl"] selectors to the left and right padding.

It seems like we've run into issues in the past with setting padding to use short-hand property syntax and bidi styling like below:

padding: var(--terra-select-padding-top, 0) var(--terra-select-padding-right, 0) var(--terra-select-padding-bottom, 0) var(--terra-select-padding-left, 0); 

My guess is the postcss-rtl plugin doesn't parse / understand the css custom property values or it may see the values are set to a nuetral, non-bidi necessary value like 0 and opt-out of creating [dir="ltr"] and [dir="rtl"] selectors. This is fine until someone themes one of the left or right padding values to be something other than 0, then there theme doesn't not work bidirectionaly.

@JakeLaCombe is likely more familiar with the details on the bidi styles issue.

Proposal

I'd recommend we disable the minimize option in the css-loader to opt-out of cssnano behavior until css-loader updates to use cssnano v4.

Using the sass-loader, CSS is already minified when webpack is run in production mode. cssnano offers a more desctructive minimization that I don't find to be completely neccessary with our current webpack setup.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

Theming styles work and theming and bidirectionality styling work together.

Bug Report

Description

When running tests out of the box with formFactor: undefined in the wdio configuration, the default viewport for the test run is defined through our docker-compose defaults giving the viewport the following sizes:

width: 1070
height: 1020

When running tests with the formFactor: 'huge' defined in the wdio configuration, the viewport size is set to Terra's huge viewport size, which is defaulted to

width: 1300
height: 768

These size difference result in differing screenshot image because of inconsistent screenshot dimensions, when these dimensions should be the same.

Expected Behavior

Screenshot width match when running with or without formFactor defined.

Environment

• Component Name and Version: ^4.4.0

Issue Description

Enable minimize option in css-loader.

Blocked by cssnano/cssnano#408 then on the css-loader to consumer the v4 version.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

Enable minimize option in css-loader, once the css-loader has been updated & released to use cssnano v4.

Current Behavior

In the current version of css-loader (0.28), if you run webpack in production mode, it will minimize the CSS with cssnano v3. The version of cssnano included as a dependency in css loader includes a bug which impacts long-hand CSS properties using CSS custom properties. Additionally cssnano v3 used an outdated version of autoprefixer and browserslist which will be bumped in the next cssnano v4.

Bug Report

Description

On Windows (not sure if it's Windows specific but I assume things have been working for the rest of the ecosystem), when running aggregate translations using the syntax specified in the doc for the aggregate-translations CLI, I get

TypeError: Cannot read property 'split' of undefined
    at addCustomDirectory (C:\workspace\dv297_personal_repo\terra-toolkit\scripts\aggregate-translations\aggregate-translations-cli.js:12:35)

Steps to Reproduce

0. Maybe run on Windows?
1. Add "aggregate-translations": "tt-aggregate-translations -b ./ -d ./translations -l ['en','es'] -o ./aggregated-translations", to NPM scripts
2. Run npm run aggregate-translations

Expected Behavior

aggregated-translations directory is created

Possible Solution

Terra-toolkit uses Commander for collecting its arguments. Not sure if something changed across versions or if it has inconsistent behavior across platforms, but when I logged out the params when running a local modified version of the CLI, I get this
// baseDirectory, searchPattern
./translations undefined

I assume the "baseDirectory" should be enough. At least when I just use that, the CLI runs fine.

Environment

• Node/npm Version: 9.8.0/ 6.2.0
• Operating System and version (desktop or mobile): Windows 10

Google Lighthouse

Scores a webpage in several categories: Performance, Progressive Web App, Accessibility, Best Practices, and Search Engine Optimization. Lighthouse also runs a variety of audits (whether or not the page has or does something) in the above categories. Lighthouse can be configured to only test specific categories or even only run specific audits.

Lighthouse visits a page and tests how long it takes to load, emulating a mobile device by default including network and CPU throttling. Lighthouse doesn't test interaction beyond scrolling down the page.

Results

We have the option of saving results as a json, html, or csv file. Lighthouse Report Viewer can take a json report and make a display from it. We also have the option of parsing the report as a javascript object directly if lighthouse is not called directly from the command line. The results show little variance between runs.

Lighthouse also collects traces (see below), logs scripts loaded, logs css rule IDs and whether or not it was used, images loaded, accessibility violations, DOM max width and height, and crawlable links.

Requirements

• Have Google Chrome installed
• UPDATE: Chrome version 66 (April 2018) is required for Lighthouse 3.0.1 (latest), Chrome 54 (October 2016) for Lighthouse 2.9.4
  Lighthouse v3 Changelog overview

Interesting Links

• lightcrawler - Crawl a website and run each page found through Lighthouse.
• webpack-lighthouse-plugin - run Lighthouse from a Webpack build.
• lighthouse-ci - Run Lighthouse and assert scores satisfy your custom thresholds.
• The above and other interesting links found here

Chrome Traces

Chrome traces collect an incredibly wide array of information about a page constantly, in the background. A full list of trace categories can be found at the tracing page by pressing Record then Edit Categories. Traces can be recorded while we run WebdriverIO tests, gathering data for a specific set of actions.

Results

The results come by default as an incredibly long array of events. There are many processors available to make sense of the events such as the Performance tab in the Dev Tools, the tracing page (chrome://tracing), or even an npm package devtools-timeline-model.

There is lots of potential information to be gleaned but processing would be dificult. Some potential uses are testing how long a script ran for (confirmed possible) or testing how long it took to download specific resources. The tracing page can give incredibly detailed information on a trace. Trace results tend to vary from run to run.

Requirements

• Manipulate webpage with Google Chrome as browser (chromedriver will work)

Notes

• Long list of Chrome command line arguments
• Notes on using Traces to test Performance
• Selenium capabilities options reference
• Enabling Performance Traces in WDIO config:

capabilities: [
    {
      loggingPrefs: {
        performance: 'ALL',
      },
      'goog:chromeOptions': {
        args: ['--enable-gpu-benchmarking', '--enable-threaded-compositing'],
        perfLoggingPrefs: {
          traceCategories: 'devtools.timeline,disabled-by-default-devtools.timeline,disabled-by-default-devtools.timeline.frame,toplevel',
        },
      },
    },
  ],

• Getting performance logs in WebdriverIO test: const logs = browser.log('performance');

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Issue Description

Docs were missed in 6d1237b. There will be a few updates needed as well. See https://github.com/cerner/terra-toolkit/pull/81/files#diff-13fc786d81ab30b80fffd3c31e7833acR36

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Feature Request

Description

Adding testURL to jest config to resolve issue related to jsdom / jest issues with the jsdom 11.12.0 release.

For reference, here is the PR for terra-core.

Issue Description

When we were working on releasing v2.0.0, we ran into the following error when running the release script.

npm ERR! code 1
npm ERR! Command failed: git add /Users/rm012685/release/terra-toolkit/package-lock.json
npm ERR! The following paths are ignored by one of your .gitignore files:
npm ERR! package-lock.json
npm ERR! Use -f if you really want to add them.
npm ERR! 

It would be good to figure out what the release script is trying to add an ignored file to our version control so we can use the latest version of npm to release without issues.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

Running the release script with npm 5 completes successfully

Summary

Our team's goal is to improve the ease of using the terra-toolkit, starting with nightwatch testing. To improve nightwatch testing, we are going to:

• Provide simpler nightwatch configuration that allows easy customization
• Remove the test scripts needed to start nightwatch testing
• Provide a responsive test helper
• Clean up documentation on nightwatch test setup

Issue Description

In toolkit v3 (#81), default webpack configuration will be included. We should include documentation on the setup, the loaders and plugins as well as explain the config since these reflect Terra's recommended setup. This would referenced by terra-ui as well.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Issue Description

Each time the visual-regression service is ran, it captures screenshots in three locations:

• diff - the difference screenshot if the screenshot is out of mismatch tolerance
• reference - the checked in 'correct' screenshots
• screen - the screenshot from the last ran test

Before grabbing new screenshots, the diff and screen directories should be emptied such that it is clear which screenshots were truly grabbed in the last test run.

Using the specs key, this cleanup is possible. I would recommend we create a new service or enhance the Terra Service to provide this functionality.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

All clean the diff and screen directories before creating new screenshots.

Current Behavior

Currently the screenshots in the diff and screen directories are only updated if a new screenshot is taken, however, stale screenshot remain. This makes it challenging to shift through the relevant screenshots given if a screenshot comparison fails.

Issue Description

This was added to move the mouse between screenshots to ensure the mouse moves (removing the hover state) if an element is clicked. This has causes unexpected test behaviors of elements losing focus when desires, closing popups/modals when desired to be open and causing errors by attempting to click when an overaly is present.

Lets change this before hook to be a this mouse move helper such that no unexpected behaviors occur while writing tests.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Issue Description

With the 2.6.0 version of axe-core, the new accessibility rule for ensuring there is a main landmark in a document. We are automatically pulling the latest release, 2.6.1 for axe-core. We should lock it down to 2.5.0 until terra-core and other libraries are updated to handle the new release.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

Dependent library, terra-core, tests should not fail when running wdio tests.

Current Behavior

When pulling in the 2.6 version of axe-core, wdio tests will fail for certain terra-core components.

Bug Report

Description

When running the command...

tt-wdio --locales ['en','en-GB','es'] --formFactors ['tiny','medium','large'] 
                                                                              

in an NPM script, I get the follow error log. Note the extra file path in the Error.

C:\FooProject/C:\FooProject\node_modules\terra-dev-site\config\wdio\wdio.conf.js

C:\FooProject
λ npm run test:wdio:locally

> [email protected] test:wdio:locally C:\FooProject
> tt-wdio --locales ['en','en-GB','es'] --formFactors ['tiny','medium','large']

module.js:545
    throw err;
    ^

Error: Cannot find module 'C:\FooProject/C:\FooProject\node_modules\terra-dev-site\config\wdio\wdio.conf.js'
    at Function.Module._resolveFilename (module.js:543:15)
    at Function.Module._load (module.js:470:25)
    at Module.require (module.js:593:17)
    at require (internal/module.js:11:18)
    at loadWdioConfig (C:\FooProject\node_modules\terra-toolkit\scripts\wdio\clean-screenshots.js:6:38)
    at cleanSnapshots (C:\FooProject\node_modules\terra-toolkit\scripts\wdio\clean-screenshots.js:15:22)
    at Object.<anonymous> (C:\FooProject\node_modules\terra-toolkit\scripts\wdio\wdio-runner-cli.js:43:1)
    at Module._compile (module.js:649:30)
    at Object.Module._extensions..js (module.js:660:10)

Steps to Reproduce

1. Run tt-wdio --locales ['en','en-GB','es'] --formFactors ['tiny','medium','large'] as an NPM script

Expected Behavior

WDIO tests run

Possible Solution

This might be a Windows related problem. The stack trace mentioned clean-screenshots.js file. I noticed that when importing the path module, the "posix" variation was used. I thought this was curious, so I changed the line.

- const { posix: path } = require('path');
+ const path = require('path');

I was able to get a little further in the process, but stopped with error...

Module not found: Error: Can't resolve 'FooProject/lib/FooProject/components/FooView' in 'C:\FooProject\lib\terra-dev-site\test'
resolve 'FooProject/lib/FooProject/components/FooView' in 'C:\FooProject\lib\terra-dev-site\test'
  Parsed request is a module
  using description file: C:\FooProject\package.json (relative path: ./lib/terra-dev-site/test)
    Field 'browser' doesn't contain a valid alias configuration
    resolve as module
      looking for modules in C:\FooProject\dev-site-config
        using description file: C:\FooProject\package.json (relative path: ./dev-site-config)
          Field 'browser' doesn't contain a valid alias configuration
          using description file: C:\FooProject\package.json (relative path: ./dev-site-config/FooProject/lib/FooProject/components/FooView)

Environment

• Component Name and Version:
• Node/npm Version: Node 9.8.0/ NPM 6.4.0
• Webpack Version: 4.16.5
• Operating System and version (desktop or mobile): Windows 10 Desktop

As stated here in the npm documentation:

A lot of packages have one or more executable files that they'd like to install into the PATH. npm makes this pretty easy (in fact, it uses this feature to install the "npm" executable.)

To use this, supply a bin field in your package.json which is a map of command name to local file name. On install, npm will symlink that file into prefix/bin for global installs, or ./node_modules/.bin/ for local installs.

Adding this field should cleanup nightwatch test scripts from

"test:nightwatch-default": "SPECTRE_TEST_SUITE=terra-overlay node ../../node_modules/terra-toolkit/lib/scripts/nightwatch.js"

to

"test:nightwatch-default": "SPECTRE_TEST_SUITE=terra-overlay node nightwatch",

The props-table component uses the bin field in the package.json and the resulting repo-wide script used is:

"props-table": "props-table ./src/ProgressBar.jsx --out-dir ./docs/props-table"

Issue Description

Selenium docker service should be updated to use docker-compose. This will enable us to create a local hub with as many instances as we want/need. This could have the ability to speed up test runs locall 4-8x

See: http://alexbiddle.github.io/2016/07/04/create-a-selenium-grid-with-docker-compose/

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Feature Request

Update repo to use terra's eslint config module

Issue Description

We need to add the ability to capture screenshots. There's a lot of potential here, and this may need to be split up into several issues, but for documentation purposes the functionality we would like to have is:

• A screenshot grabber that captures screenshots
• Some mechanism to compare screenshots against an "official version"

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Issue Description

Whoops. We pull in mock theme for our repos, however this configuration should not be defined in the toolkit's default webpack config, but terra-dev-site's webpack config.

Remove https://github.com/cerner/terra-toolkit/blob/master/config/webpack/webpack.config.js#L70

Issue Description

Translation errors are misleading. Update to give a more meaningful error message

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

When there is an error getting translations generated, the exception message should be given to the user.

Current Behavior

We swallow the exception and just tell them the file is not found which is not always correct.
An engineer struggled with this for a while because the file had a trailing comma. If the exception had been given instead,
debugging would have been easier

Steps to Reproduce

1. Add an extra trailing comma in your translation file
2. Run your commands to generate translations (for us its booting webpack)
3. See the output Translation file en.json not found for /Users/as027811/code/hlife/education/translations
4. See that this file exists
5. Be confused and cry on the inside

➜  education git:(master) ✗ cat /Users/as027811/code/hlife/education/translations/en.json 
{
  "Education.I18nTest.message": "Test translation loaded from translations/en.json",
}

Proposed Fix

Change the console warning to something like
console.warn(There was an error reading your translations file ${translationFile}. \n Exception Message: ${e.message} \n)

and then you getting errors like

There was an error reading your translations file /Users/as027811/code/hlife/education/translations/en.json. 
 Exception Message: Unexpected token } in JSON at position 87 

There was an error reading your translations file /Users/as027811/code/hlife/education/translations/en-US.json. 
 Exception Message: ENOENT: no such file or directory, open '/Users/as027811/code/hlife/education/translations/en-US.json' 

NOTE: the second file is actually not found, so the old error message still works basically

➜  education git:(master) ✗ ll /Users/as027811/code/hlife/education/translations
total 16
-rw-r--r--  1 as027811  WHQ_NT_DOMAIN\Domain Users  225 May  2 09:39 en-US-2.json
-rw-r--r--  1 as027811  WHQ_NT_DOMAIN\Domain Users   90 May  2 09:47 en.json

Issue Description

In the wdio config, consumers have ability to specify a custom docker-compose.yml. However, in the nightwatch tests, this is not currently an option, so consumer are locked to our default docker-compose file.

Issue Description

CSS files generated through webpack by utilizing shareable webpack config provided by terra doesn't have -webkit-flex styles.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

CSS generated should have -webkit-flex styles.

Current Behavior

Steps to Reproduce

Environment

• Component Version: terra-toolkit 3.4.0
• Browser Name and Version: PhantomJS
• Operating System and version (desktop or mobile):

Issue Description

Today each of our mono-repos has a dependency on webpack, express, and webpack-dev-server. This can make updating and maintaining these repos painful.
Similarly our consumers have had trouble in the past setting up webpack for terra. We have a default webpack config in terra-dev-site, but it is customized to the needs of terra-dev-site.

I propose that we have terra-toolkit take on the responsibility of offering up the default 'terra' webpack config as well as abstracting the webpack dependency to a single package. This config will be our default config to build build a vanilla terra website.

Our i18n setup makes sense to include in our vanilla config, but we don't want terra-toolkit to depend on the i18n package from terra-core. We will move the aggregation script from the i18n package, make the i18n package dependent on terra-toolkit and alias the script for passivity.

In Terra-toolkit, at a minimum, we will offer a 'compile' script that takes a webpack config, but knows how to fall back to the default webpack config housed in terra-toolkit. This will allow us to abstract webpack away from the mono-repos yet still give consumers the choice to either rely on terra for compilation or to supply their own webpack config, or neither and roll their own webpack confing and depend on whatever version of webpack they desire.

Terra-dev-site will consume terra-toolkit and offer up it's own 'compile' script that will inject terra-dev-site generation logic in front of using the default webpack config from terra-toolkit. Terra-dev-site will also offer up running either a webpack-serve (dev) or an express server (prod) as scripts too. I'll have to think more if parts of those servers should be pushed back into terra-toolkit.

Terra-X (mono repo) will consume terra-toolkit for testing and terra-dev-site for hosting because they want to use terra-dev-site to host their test routes.

Our consumers interested in creating apps will not consume terra-dev-site and instead either consume the compile command in terra-toolkit or use the provided webpack config as a base to start with.

This will be a non-passive change for both terra-dev-site and terra-toolkit, though the mono-repos will be unaffected because terra-toolkit and terra-dev-site are both just dev dependencies.

Next Steps

• Migrate the script aggregate translations to terra-toolkit
• Upgrade ExpressDevServerService to take an optional fs and build directory to allow terra-dev-site to offer it's own compiled assets.
• Create default webpack config and upgrade terra-toolkit to webpack 4. Include i18n.
• Update default terra-toolkit screenshot names to: screen/locale/browser/test_suite/[test.parent][test name].HeightxWidth.png
• Provide intelegent defaults for wdio config (ideally zero config for mono-repos and consumers)
• Remove webpack-dev-server-service from terra-toolkit
• More tbd

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Issue Description

In 195e65a, I refactored the function to use an array of arguments and check the length of that array to see if the developer wanted to use a name, a hash, or both for checking theming. However, this refactor prevents matchScreenshot from reading in the name if it's the only argument.

Steps to Replicate.

1. Write the code Terra.should.matchScreenshot('1'); for a screenshot test.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

It creates a screenshot named "1".

Current Behavior

It skips the name argument, and produces a screenshot with the name "default".