Closed Harminder84 closed 1 month ago
Latest commit: 228966469f221a63742754cb8054a1e14ec0ce5a
The changes in this PR will be included in the next version bump.
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
Name | Link |
---|---|
Latest commit | 228966469f221a63742754cb8054a1e14ec0ce5a |
Latest deploy log | https://app.netlify.com/sites/compiled-css-in-js/deploys/66d66bac38a946000885b93a |
I decided to try to patch @compiled/webpack-loader
. Another option would be deleting examples/parcel/
entirely to remove the webpack
dependency, but I felt it would still be useful to have a fully functioning webpack example app in the repo - at least for the time being...
Don't think there would be any perf regressions from this(?) but let me know if there are
Update: I have also updated .github/workflows/test.yml
to include a yarn build
step before yarn test
. This is because of a breaking change in enhanced-resolve
v5.17.1 (and also webpack
5.94.0) that changes how the @compiled/react/runtime
package in our tests is resolved.
Previously, when resolving @compiled/react/runtime
inside our examples/webpack-loader
tests, Webpack would load the exports
field in packages/react/package.json
. Since the strings inside exports
are provided as arrays, an older version of enhanced-resolve
would try each path in an array until it matches a valid path.
For example, when given this...
"./runtime": {
"import": [
"./dist/esm/runtime.js",
"./src/runtime.ts"
],
"require": [
"./dist/cjs/runtime.js",
"./src/runtime.ts"
]
},
... an older version of enhanced-resolve
would try to resolve the first entry ./dist/esm/runtime.js
, and then if that doesn't work, it will try to resolve the second entry ./src/runtime.ts
.
However, in the current version of enhanced-resolve
, it will only try to resolve the first entry in the array. If the first entry in the array cannot be resolved, it will throw an error. In this case, it'll try to resolve ./dist/esm/runtime.js
, and since that doesn't exist because we haven't run yarn build
, it will throw an error and the test will fail.
The easiest solution is to ensure that ./dist/esm/runtime.js
exists when we run our tests, hence we run yarn build
before yarn test
. Another solution exists (modifying packages/react/package.json
) but it's a bit risky as it can affect products that depend on Compiled.
Note that even though we don't use webpack directly, the same breaking change has been made in webpack:
Snyk has created this PR to fix 1 vulnerabilities in the yarn dependencies of this project.
Snyk changed the following file(s):
examples/webpack/package.json
Note for zero-installs users
If you are using the Yarn feature zero-installs that was introduced in Yarn V2, note that this PR does not update the
.yarn/cache/
directory meaning this code cannot be pulled and immediately developed on as one would expect for a zero-install project - you will need to runyarn
to update the contents of the./yarn/cache
directory. If you are not using zero-install you can ignore this as your flow should likely be unchanged.⚠️ Warning
``` Failed to update the yarn.lock, please update manually before merging. ```Vulnerabilities that will be fixed with an upgrade:
SNYK-JS-WEBPACK-7840298
Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information: 🧐 View latest project report 📜 Customise PR templates 🛠 Adjust project settings 📚 Read about Snyk's upgrade logic
Learn how to fix vulnerabilities with free interactive lessons:
🦉 Cross-site Scripting (XSS)