I've been running my component tests via cypress open-ct for a while now, relying on importing /node_modules/tailwindcss/dist/tailwindcss.min.css.
Since upgrading to Tailwind v3 some of my tests are failing as there is no prebuilt CSS file I can import - everything is generated just in time.
For example, testing if a modal closes when clicking on a overlay that is fixed and full width fails as the whole modal is rendered so that it is inaccessible by Cypress.
Another side-issue that stems from not having access to Tailwind classes is that videos recorded when running tests in CI are unusable as they are just a bunch of random native elements.
I've been importing Tailwind like this at the top of each Test file (before describes)
import { mount } from '#cypress/vue'
import '/node_modules/tailwindcss/dist/tailwind.min.css'
import MultiSelectField from './MultiSelectField.vue'
import { ref } from "vue";
Any ideas how to include Tailwind (preferably globally) so tests won't fail?
You can use the Tailwind CLI to generate your stylesheet on the fly.
Add this plugin in cypress/plugins/tailwind.js (be sure to change the -i source from ./src/styles/globals.css to your base CSS file):
before(() => {
cy.exec('npx tailwindcss -i ./src/styles/globals.css -m').then(
({ stdout }) => {
if (!document.head.querySelector('#tailwind-style')) {
const link = document.createElement('style')
link.id = 'tailwind-style'
link.innerHTML = stdout
document.head.appendChild(link)
}
},
)
})
Then, load the plugin by importing it in cypress/support/index.js:
import '../plugins/tailwind'
You should also set up a separate config file for your component tests, such as cypress/support/component.js, and specify that in your cypress.json config file:
{
"component": {
"supportFile": "cypress/support/component.js",
},
"e2e": {
"supportFile": "cypress/support/e2e.js"
}
}
Then, only include import '../plugins/tailwind' in your cypress/support/component.js config file, so that you don't perform the JIT compilation for your E2E tests (since it's unnecessary).
Michael Hays' solution works, but it rebuilds the whole .css file every time changes to the code are made, which slows tests down. An alternative would be to run tailwind externally in watch mode.
npm i -D concurrently
package.json
"scripts": {
"test": "concurrently \"tailwindcss -i ./src/index.css -o ./dist/index.css --watch\" \"cypress open\" "
},
cypress/support/component.ts
import "../../dist/index.css";
I see you're using import '/node_modules/tailwindcss/dist/tailwind.min.css' which expects a pre-compiled bundle. If you have any customization added to the tailwind config, those would not be covered.
But if you can't use the generated css and don't have any tailwind customization, you could use the cdn version from https://cdn.tailwindcss.com/
Because you are running it in a test and don't want to add to possible "flakyness" of using remote dependency, you'll likely want to download that file and keep it in the repo and update it manually from time to time. You can also use some automation for getting the correct version from the cdn before running the test, but Ideally you'd use the generated css, since that's what you're shipping so that's the resource that should be getting tested.
Related
I'm building an internal tool in Laravel and I need a datetime picker for part of the interface. My research has suggested that Tempus Dominus is the solution most people use to solve this.
I've installed Tempus Dominus and Moment (through Node) and added them both to my app.js file. However when I try to compile the JS I get the following warning:
WARNING in ./node_modules/moment/min/moment.min.js
Module not found: Error: Can't resolve './locale' in 'C:\inetpub\wwwroot\salesdb\node_modules\moment\min'
# ./node_modules/moment/min/moment.min.js
# ./resources/js/app.js
# multi ./resources/js/app.js ./resources/sass/app.scss
This is how I'm importing them in the app.js file:
require('moment/min/moment.min.js');
require( 'tempusdominus-bootstrap-4/build/js/tempusdominus-bootstrap-4.js');
What am I missing?
The official Tempus Dominus Bootstrap plugin is unmaintained and is kinda buggy when it comes to ES6 and module bundlers.
I strongly advise you to install these two forks instead:
https://www.npmjs.com/package/tempusdominus
https://www.npmjs.com/package/tempusdominus-bootstrap
npm i tempusdominus tempusdominus-bootstrap
If you wanna make it work, you should inject/provide moment and jquery imports in the final build of your application (1st option), or make them globally available (2nd option).
1st option
What is your module bundler?
E.g., if you are using Rollup, you can configure the build like this using the Rollup's #rollup/plugin-inject plugin:
// Your imported plugins...
import inject from "#rollup/plugin-inject";
export default {
input: "src/index.js",
output: [
// You outputs...
],
plugins: [
inject({
$: "jquery",
jQuery: "jquery",
moment: "moment",
exclude: "src/**",
}),
// Your other Rollup plugins here...
],
};
For Webpack, you'd need to use the ProvidePlugin:
const webpack = require('webpack');
module.exports = {
entry: './index.js',
output: {
filename: '[name].js'
},
plugins: [
new webpack.ProvidePlugin({
$: 'jquery',
jQuery: 'jquery'
moment: 'moment'
})
]
};
2nd option
The other option would be to make moment and jQuery globally available in your app by adding the following lines to your index.js main entry point file:
import moment from "moment";
import $ from "jquery";
window.$ = window.jQuery = $;
window.moment = moment;
// Your other imports (tempusdominus-bootstrap as well) go here...
Though I didn't test, both options should work (let me know if not).
Of course, the preferred one would be to use a module bundler (1st option) and not to expose jQuery and/or moment to window.
And if you are using React, I advise you to use this library here instead (demo here). But that's another story.
I created new folder 'apitests' in cypress project and created a JavaScript test file in it. It does not show up in the test runner.
I have used the default configuration in cypress.json as specified in Cypress documentation
"testFiles": "**/*.*",
I expected my new folder 'apitests' and JavaScript test file to show in the test runner. Here is the end result.
Here is the file structure.
You've put your apitests folder directly in cypress/, while Cypress by default looks in cypress/integration/ folder.
You can change that by using integrationFolder config option, but I'd personally just keep the spec files in cypress/integration as is the default.
I had to add this to cypress.config.js:
module.exports = defineConfig({
e2e: {
specPattern: [
'cypress/e2e/*.js',
'cypress/e2e/**/*.js'
]
}
});
I had it initially, but removed it, to hope that Cypress would automatically find all my tests. But that resulted in new tests not being added to the test-runner.
My Cypress-version: 11.x.x (and I updated to 12.0.2 as a debugging attempt).
The solution was found in the Cypress-documentation for config.
You've put your apitests folder directly in cypress/, while Cypress by default looks in cypress/integration/ folder.
You will get an idea about it
We're using Cypress for testing an app build with Create React App, and our CRA app is setting a custom import path in .env – NODE_PATH=src/ – so that we can import files "absolutely", e.g. import Foo from 'components/Foo' vs. import Foo from '../../components/Foo'
The problem is, if we import one of the files from our CRA into a Cypress test, and the imported file includes something like import routes from 'lib/routes' Cypress doesn't know how to process that path and the import fails.
Example
Let's say we have the following files:
/cypress/integration/test.js
import routes from '../../src/lib/routes';
// Tests here…
/src/lib/routes.js
import { routeHelpers } from 'lib/routes';
// Routing code here
In this scenario, when /cypress/integration/test.js imports /src/lib/routes.js it will encounter the absolute import of 'lib/routes' and have no idea how to resolve that path.
Is there a way to set custom paths for Cypress to include when searching for imports in this way? In the case of this arbitrary example, it would mean telling Cypress to use src as a directory to resolve imports from.
Easiest solution for this turned out to be simply running the cypress commands with NODE_PATH=src. So my package.json was simply updated to the following:
"scripts": {
"cypress:open": "NODE_PATH=src cypress open",
"cypress:run": "NODE_PATH=src cypress run",
},
I had a similar issue and I was using .env with NODE_PATH=src
Solution: I removed .env and created jsconfig.json for absolute imports.
{
"compilerOptions": {
"baseUrl": "src"
},
"include": ["src"]
}
This is the recommended approach in the CRA docs: https://create-react-app.dev/docs/importing-a-component/#absolute-imports
I've been trying to use the mocha require option:
mocha mytest.js --require myglobals.js
But I don't know how to do it from karma. The idea is to run karma start and it will automatically require myglobals.js.
Is that possible to do it from within karma.conf.js or somehow else?
Maybe I'm not using karma/mocha in the right way.
My idea is:
I want to have unit/integration tests for both the client (react) and the server (node/express)
I want to just run karma start and both client and server tests are tested
I found very useful to have the following file pre-required, in order to avoid requiring some things in all tests:
myglobals.js:
const chai = require('chai');
// Load Chai assertions
global.expect = chai.expect;
global.assert = chai.assert;
chai.should();
// Load Sinon
global.sinon = require('sinon');
// Initialize Chai plugins
chai.use(require('sinon-chai'));
chai.use(require('chai-as-promised'));
chai.use(require('chai-things'));
For the server side I've made it work using the command:
mocha mytest.js --require myglobals.js
But still, I wanted to keep it running under the npm run test (which calls karma start) instead of creating another npm run test:server command.
Furthermore, I wanted to do the same on the client. I'm using webpack there as a preprocessor.
Any ideas if it is possible to accomplish that? Or maybe I'm in the wrong way?
Short Answer
Mocha in the browser does not support an equivalent of the --require option, but you do not need it. You can just load whatever you need ahead of your tests listing the files you want to load in files in front of your test files. Or if you use a loader like RequireJS, write a test-main.js that loads the modules you would load with --require first, and then load your test files.
Long Answer
If you look at Mocha's code you'll see that the only place --require is used is in the bin/_mocha file. This option is not passed further into the Mocha code but is immediately used to load the requested modules:
requires.forEach(function(mod) {
require(mod);
});
When you run Mocha in the browser, none of this code is run, and if you look in the rest of the Mocha code you won't find a similar facility anywhere else. Why?
Because it would serve no purpose. The --require option is very useful at the command line. Without it, the only way to load modules before Mocha loads the test files would be to either write custom code to start Mocha or put the necessary require calls at the start of every single test file.
In the browser, if you do not use a module loader, you can just load the code you'd load using --require by putting the script elements that load them in front of the script elements that load your tests. In Karma, this means putting these files earlier in the list of files you have in your karma.conf.js. Or if you use RequireJS, for instance, you write test-main.js so that the loading is done in two phases: one that loads the modules you'd load through --require on the command-line, and a second that loads your test files. It could be something like:
const allTestFiles = [];
const TEST_REGEXP = /test\/test.*\.js$/i;
Object.keys(window.__karma__.files).forEach((file) => {
if (TEST_REGEXP.test(file)) {
const normalizedTestModule = file.replace(/^\/base\/|\.js$/g, "");
allTestFiles.push(normalizedTestModule);
}
});
require.config({
baseUrl: "/base",
paths: {
...
},
});
// This guarantees that "a", "b", "c" loads before any other module
require(["a", "b", "c", ...], () => {
require(allTestFiles, window.__karma__.start);
});
Does anyone know if there is a way to combine multiple SASS/SCSS files into one SASS/SCSS file. I do mean "into one SASS/SCSS" and not into a CSS file.
For example, I have 3 scss files:
app.scss
base.scss
layout.scss
The app.scss file contains 2 imports to base.scss and layout.scss.
I would like to beable to generate 1 SCSS file that basically concatenates the files and does not process the sass.
It's fairly difficult to search for as everything that gets return is to do with combining into CSS.
Why would I want to do this? Basically, I'd like to easily reference a set of SCSS files from within a codepen (other online code editor).
Thanks
I analyze all files by the mask, find all imports inside and concatenate into one file. So I don't need one entry point
npm install -D bundle-scss
"script": {
"postbuild": "npm run themes",
"themes": "bundle-scss -m \"./src/**/*.theme.scss\" -d \"./dist/themes.scss\""
}
scss-bundle solves this problem
https://github.com/reactway/scss-bundle
Caution: Does not support newer module based imports. Issue #90
You could modify this for javascript. Kept it in typescript as I am currently solving this issue on my own (angular 6 library), and ran into this question.
According to the docs, angular material uses this implementation.
import * as path from 'path';
import { Bundler } from 'scss-bundle';
import * as fs from 'fs';
(async () => {
// Absolute project directory path.
// Assuming all of your scss files are in `./projects/my-library/src/styles`
const projectDirectory = path.resolve(__dirname, './projects/my-library/src/styles');
const bundler = new Bundler(undefined, projectDirectory);
// Relative file path to project directory path.
// The name of your file here would be `app.scss`
// Kept this here if anyone runs into this answer and wants to do this with the new angular 6 library.
const { found, bundledContent } = await bundler.Bundle('./_all-theme.scss');
if (found && bundledContent) {
// where you want to save the file, and what you would like it to be called.
const location = path.resolve(__dirname, '_theming.scss');
fs.writeFileSync(location, bundledContent);
}
})();