Is it possible to place Cypress tests in existing React file architecture - reactjs

I know that their patterns say to place all Cypress tests/integrations in the cypress/integration path. However, I would like to place the tests in the src/components path.
src
└── components
└── Component1Directory
├── Component1.js
└── tests
└── cypress_integration_for_component_1.js
└───Component2Directory
├── Component2.js
└── tests
└── cypress_integration_for_component_2.js
I have tried to change the config but wild cards do not seem to work.
{
"baseUrl": "http://localhost:4001",
"integrationFolder": "src/components/*/tests"
}
I also tried removing the test sub dir using a wild card in place of "tests" but that also did not work.

I updated the file name to be
*.cy.js
and updated the config to be
{
"baseUrl": "http://localhost:4001",
"integrationFolder": "src/",
"testFiles": "**/*.cy.js"
}
This allows the tests to be found in the existing file structure.

Related

How to serve a file for any matching GET request with warp?

I am using React in the frontend development and doing client-side routing with react-router. While intergating with my warp backend, I have come across some obstacles.
After building the React app with npm run build, I move the build folder to my Rust project. According to create-react-app documentation. I need to serve build folder and serve the index.html file for any matching GET request. I could not achieve this in warp like the express example in the documentation.
Here is the build folder example.
build
├── asset-manifest.json
├── favicon.ico
├── index.html
├── manifest.json
├── robots.txt
└── static
├── css
│   ├── main.089e2544.css
│   └── main.089e2544.css.map
└── js
├── main.ba6a006a.js
├── main.ba6a006a.js.LICENSE.txt
└── main.ba6a006a.js.map
3 directories, 10 files
Here is index.html line where includes the script.
<script defer="defer" src="/static/js/main.ba6a006a.js"></script>
Using warp::fs::dir("build") was enough to see main page since it includes index.html file in the background. But if I to manually type URL for example 127.0.0.1:8080/login and press enter it does not process the request.
The way to implement a "fallback" is to simply use .or() which will attempt to use the next filter if the one before didn't match. So if the required behavior is to serve from the "build" directory or else serve "build/index.html", that can be done like this:
use warp::Filter;
#[tokio::main]
async fn main() {
let routes = warp::filters::fs::dir("build")
.or(warp::filters::fs::file("build/index.html"));
warp::serve(routes)
.run(([127, 0, 0, 1], 8080))
.await;
}

Disable Specific Paths for Next.JS File System Routing [duplicate]

There are SSR-related problems with several pages in Next.js project that results in errors on npm run build and prevent the project from being built:
pages/
foo/
bar/
[id].jsx
index.jsx
index.jsx
...
For example, bar:
export function getStaticProps() {
return someApiCallThatCurrentlyFails()
...
}
export default function Bar() {...}
As a quick fix, it may be convenient to just not build bar/*.* pages and make routes unavailable.
Can pages be ignored on Next.js build without physically changing or removing page component files in the project?
You can configure the pageExtensions in the next.config.js.
// next.config.js
module.exports = {
pageExtensions: ["page.js"],
}
After configuring this, the only pages with *.page.js will be considered in the below given directory structure.
pages/
├── user
│ └── setting
│ ├── index.js
├── _app.page.js
├── _document.page.js
├── list.page.js
└── theme.ts
Custom file ignores patterns that are not supported yet. You can visit the PR created here, and the solution given here. This is the most satisfactory solution so far.
#Mathilda Here from Nextjs docs: it's necessary for all pages including _app, _document, etc.
https://nextjs.org/docs/api-reference/next.config.js/custom-page-extensions
Changing these values affects all Next.js pages, including the following:
- middleware.js
- pages/_document.js
- pages/_app.js
- pages/api/
For example, if you reconfigure .ts page extensions to .page.ts, you would need to rename pages like _app.page.ts.

What is the right way to incude Sass in NextJs?

When I use Sass files in NextJs, I am getting 'conflicting order' warnigs from mini-css-extract-plugin. The conflict always messes up my stylings on build. You can see the error described in the following link:
https://medium.com/iryl/control-css-imports-order-for-next-js-webpack-based-production-applications-3b69765444fd
This is an article with a solution to this issue but it talks about ordering Sass files for only one page. I'm not sure how to do order when there are multiple pages. How can I tackle the conflicting order issue?
if you are using nextjs 9.3 or higher you can use it like css modules. At least this is how they recommend that you do it.
This is an example.
You can also check the Sass support on the Next.js docs.
-- Update
The best way of do it it's by creating a different scss module for each component. It will look something like this.
Components
├── Header
│ ├── Header.js
│ ├── Header.module.css
├── Footer
│ ├── Footer.js
│ ├── Footer.module.css
├── Nav
│ ├── Nav.js
│ ├── Nav.module.css
The main idea of using css modules it's to prevent you from use a global sheet. this way the css will be optimized on the code splitting by components and you don't have to worry about declaring the same class twice, each css module file will generate a unique class name.
I'm working on a project using css modules, the project isn't done yet but the file structure it's almost the same working with sass, you can give it a look if you want.
https://github.com/edgarlr/portfolio/tree/main/components

How to set up a chrome extension using React and TypeScript with multiple pages and entry points?

There are plenty of questions and tutorials on this topic, but none of them cover all use cases for a chrome extension, because most of them assume there's only one entry point.
Here are the requisites:
Multiple "single page applications":
1) popup.html for the extension pop up page
2) options.html for the options page
3) custom.html this is a custom .html file that the extension can refer to "locally"
Each of these files are entry points for React to manipulate the DOM, but they behave independently of each other.
Non React TypeScript files
They must not be bundled together with any other scripts, and gets compiled to its own JavaScript file, for example a background.ts that compiles to background.js (which is refered to in the manifest.json).
I assume this is doable with TypeScript, React and Webpack but I'm not sure how to approach that.
There is a custom CRA template that exactly fits your needs: complex-browserext-typescript.
Usage:
npx create-react-app my-app --template complex-browserext-typescript
By default it sets up 4 entry points associated with page-like extension components:
popup (src/index.tsx) - extension's popup page, replaces the
default index entry point.
options (src/options.tsx) - extension's options page.
background (src/background.ts) - background script.
content (src/content.ts) - content script.
However there is an option to exclude any of the above components except the popup from compilation as well as add extra HTML page(s).
Also see this article for usage example.
I found a solution but it was not using create-react-app and webpack. It looks like parcel supports multiple entry points out of the box without any configuration.
Assuming a directory structure like this:
├── chrome
│   └── background.ts
├── html
│   ├── custom.html
│   ├── options.html
│   └── popup.html
├── manifest.json
├── package.json
├── react
│   ├── custom.tsx
│   ├── options.tsx
│   └── popup.tsx
With Parcel.js you simply do:
parcel build html/*.html react/*.tsx chrome/*.ts
And it will handle the multiple entry points. I created a repository that contains a template for that approach, it contains a fully runnable example.

How can I use ComponentName.js instead of index.js when importing React component (from Atomic design structure directory)

I am using Gatsby (React) for my project. I am using Atomic design folder structure e.g:
src/components/Organisms/Header
In this folder I like to have:
src/components/Organisms/Header/header.js
src/components/Organisms/Header/header.module.scss
How can I import header.js from within src/components/layout.js like:
import Header from '#components/Organisms/Header'
instead of:
import Header from '#components/Organisms/Header/header'
Update:
I managed to do it by:
adding an index.js file to src/components/Organisms/Header/
and export { default } from './header'; in index.js
But are this best practices?
You have a few options here. With all of these you would import src/components/Header.
1. Flat with no component directory (my preference):
src
└── components
├── Header.js
└── header.module.css
Benefits
Less meaningless nesting
No conflicting/confusing filenames open in your editor (e.g. index)
Easy to follow the imports and exports
Drawbacks
Nowhere for one-off resources and sub-components to go
2. Adjacent component and resources-directory (Ruby-style):
src
└── components
├── Header
│   ├── header.module.css
│   └── logo.png
└── Header.js
Benefits
Resources and sub-components are kept together
No conflicting/confusing filenames open in your editor (e.g. index)
Easy to follow the imports and exports
Drawbacks
The component isn't adjacent to resources, so imports require a ./Header/ prefix
Depending on the sorting, the resources directory may not be listed immediately adjacent to the component
3. With a directory index that exports Header:
src
└── components
└── Header
├── Header.js
├── header.module.css
├── index.js
└── logo.png
Benefits
Component and resources are kept together
Sorting doesn't matter
Drawbacks
Conflicting/confusing filenames open in your editor (e.g. index)
Confusing imports and exports, may cause hard-to-diagnose errors
Extra work for every component

Resources