- Single char alternation (e.g. a|b|c|d) in a RegExp can be simplified to use a character class ([abcd]) instead.
This usually also provides slightly better matching performance.
- Character escapes that are replaceable with the unescaped character without a change in meaning. Inside the square brackets of a character class, many escapes are unnecessary that would be necessary outside of a character class. For example the regex [\.] is identical to [.]
- If several qualified expressions occur after the qualifier having been checked for nullable, they can be replaced with optional chaining
* fix(misc): avoid issues with refs in SVGs
The previous "import friendly" syntax was actually disabling refs in SVGs parsed by svgr.
I found 3 possible solutions:
1. Removing "![path]"
2. Separating "+ref![path]" with another comma: "+ref,![path]"
3. Rewriting the loader entry in the style of the other loader entries
I chose the last one for added clarity within the file.
* fix(core): fix compilation errors
* fix(core): resolve webpack loaders with `require.resolve()`
With strict package managers such as pnpm or Yarn PnP, transitive
dependencies are *not* hoisted to the root node_modules folder. This
means that a webpack config defined within a package like
'@nrwl/cypress' cannot resolve loaders like 'ts-loader', unless
'ts-loader' is declared in the workspace's own package.json.
This is a problem because the workspace might define a different version
of 'ts-loader', incompatible with the version declared by
'@nrwl/cypress/package.json'. The workspace should not need to declare
a dependency on 'ts-loader' anyway.
See also:
* https://github.com/pnpm/pnpm/issues/801
* https://github.com/webpack/webpack/issues/5087
* fix(core): resolve absolute 'raw-loader' path
When replacing the 'raw-loader' rule in the `getStylesPartial` function,
check for the absolute path of 'raw-loader' rather than just the name.
With strict package managers such as pnpm or Yarn PnP, transitive
dependencies are *not* hoisted to the root node_modules folder. This
means that a webpack config defined within a package like
'@nrwl/cypress' cannot resolve loaders like 'ts-loader', unless
'ts-loader' is declared in the workspace's own package.json.
This is a problem because the workspace might define a different version
of 'ts-loader', incompatible with the version declared by
'@nrwl/cypress/package.json'. The workspace should not need to declare
a dependency on 'ts-loader' anyway.
See also:
* https://github.com/pnpm/pnpm/issues/801
* https://github.com/webpack/webpack/issues/5087
* fix(nextjs): fix issue where using .ts files in next.js app would result in a compile error
The issue was just a misconfiguration in the next's config.ts file: Webpack was only applying the
babel loader on .tsx files.
The updated regex will now load both .ts and .tsx files.
ISSUES CLOSED: #2249
* cleanup(testing): add missing tests for pull request #2276
Co-authored-by: tdnll <40502786+tdnll@users.noreply.github.com>
