Missing `sass-embedded` peer dependency #70020

rtritto · 2024-09-12T10:04:04Z

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/gracious-voice-8mxdxl?workspaceId=eb53ed51-e5b9-4293-8298-f0747af5ed78

To Reproduce

create-next-app
add sass-embedded
create a .scss file and import
next dev

Current vs. Expected behavior

Current

next tried to access sass (a peer dependency) but it isn't provided by its ancestors; this makes the require call ambiguous and unsound.

Required package: sass
Required by: next@npm:14.2.8 (via C:\<WORKSPACE>\node_modules\next\dist\compiled\sass-loader\)

To use Next.js' built-in Sass support, you first need to install `sass`.
Run `npm i sass` or `yarn add sass` inside your workspace.

Learn more: https://nextjs.org/docs/messages/install-sass

Expected:

No error and sass-embedded ia an optional peer dependency

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Home
  Available memory (MB): 32510
  Available CPU cores: 16
Binaries:
  Node: 22.3.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.8 // There is a newer version (14.2.10) available, upgrade recommended!
  eslint-config-next: 14.2.8
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.4
Next.js Config:
  output: N/A
 ⚠ There is a newer version (14.2.10) available, upgrade recommended!
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
   Read more - https://nextjs.org/docs/messages/opening-an-issue

Which area(s) are affected? (Select all that apply)

create-next-app, Runtime, Webpack

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

sass-embedded support is already added in #64577 (discussion #36160)

The text was updated successfully, but these errors were encountered:

samcx · 2024-09-24T22:34:13Z

@rtritto Gathered from that :pr: :

You need this in your next.config

  sassOptions: {
    implementation: 'sass-embedded'
  }

It looks like we need to also update some documentation, will go ahead and do that before closing this issue.

…and update `sassOption` types (#70428) ## Why? We currently don't document the `implementation` property for `sassOptions`. Since this is one our maintained properties, we should also update the types for `sassOptions`. - Fixes #70020 --------- Co-authored-by: Zack Tanner <[email protected]> Co-authored-by: JJ Kasper <[email protected]>

@samcx

chore: codemod versions chore: remove chalk, use picocolors refactor chore: select codemods to run restore unexpected deletion ncc compiled refac: fetch next package after prompt wip before using next-test-util add find-up better handle package test: add basic test test: prompt test: fix temp dir names try try2 try try 3 is CNA np? is CNA np? set initial for codemod revert next codemod v15.0.0-canary.167 [Turbopack] fix rsc chunking optimization (#70461) * While looking for server component entries and client components, look for server utils too * Create a separate chunk group for server utils * Mark all user imports in the rsc entrypoint has server component entries * Fix order of imports to allow proper caching --------- Co-authored-by: Niklas Mischkulnig <[email protected]> Turbopack: allow shadowing the `require` global in ESM (#70453) Closes PACK-3275 Among other things, a regression from #70255, but it could also happen with `__dirname`. To prevent `SyntaxError: Identifier 'require' has already been declared` Add cause to turbopack-node error (#70456) Occurs for example in ``` Failed to load chunk server/chunks/08b5e__pnpm_560cbe._.js .... Caused by SyntaxError: Identifier 'require' has already been declared .... ``` test: disable next/test tests (#70460) chore(workflow): typo `popular-prs.ts` path (#70462) add @taskr/esnext to pnpm root to resolve hoisting issues (#70349) Add `@taskr/esnext` to the root package.json to get around hoisting rules breaking `taskr`'s automatic discovery (and fix builds on some platforms where it is broken). Some types of 'magically' imported packages (such as taskr automatically supporting es6 by just adding a package, or drizzle automatically finding a database driver) aren't hoisted on some platforms in the way the tool expects, breaking it. The symptom of this is taskr throwing a syntax error on some platforms, because we use ES6 syntax and it can't find the package it needs to support it. By adding it to the root package.json we ensure it is always hoisted in the way taskr expects. Turbopack: fix another case of edge runtime warnings (#70455) Closes PACK-3276 v15.0.0-canary.168 Extend support of Pages router to React 18 (#70219) codemod(turbopack): Inline trivial uses of `let this = self` (#70431) A follow-up to the #70431 codemod diff, which leave behind a lot of trivial `let this = self;` statements. Using the following ast-grep rule config: ```yaml language: rust id: inline_trivial_this utils: block-with-this: all: - pattern: $BLOCK - kind: block - has: all: - pattern: let this = $SELF; - any: - pattern: let this = self; - pattern: let this = &self.0; rule: matches: block-with-this rewriters: - id: remove-let-this rule: pattern: let this = $SELF; fix: "" - id: inline-this-auto-deref rule: pattern: this inside: kind: field_expression transform: SELF_AUTO_DEREF: replace: source: $SELF replace: "&?(?<INNER>.*)" by: "$INNER" fix: $SELF_AUTO_DEREF - id: inline-this rule: pattern: this fix: $SELF transform: NEW_BLOCK: rewrite: source: $BLOCK rewriters: - remove-let-this - inline-this-auto-deref - inline-this fix: $NEW_BLOCK ``` Applied with ``` sg scan -U -r ../codemod_inline_trivial_this.yml . ``` Fix comment numbering in middleware example in docs (#70465) This PR fixes a numbering issue in the example code of the documentation. The comments in the code jumped from step 3 to step 5, so I renumbered them to maintain the correct sequence. Correcting the comment numbering improves the clarity and readability of the code, ensuring that readers can follow the steps in the right order. I changed step 5 to step 4 and step 6 to step 5, adjusting the comment sequence without altering the logic or functionality of the code. ![image](https://github.com/user-attachments/assets/12b15de3-2cc3-4dca-9185-cde5a97cd0c3) Co-authored-by: JJ Kasper <[email protected]> feat(next-swc): lint for `ssr: false` in server components (#70378) Co-authored-by: Jiachi Liu <[email protected]> [Turbopack] fix a bunch of bugs and inefficiencies in the call graph (#70243) * switch remove vs change order * take_collectibles does not need to return an Option * avoid double Option * fix edges set bugs * remove collectibles from outdated collectibles * remove unneccessary remove Basic implementation of cache-wrapper with RSC serialization (#70435) Co-authored-by: JJ Kasper <[email protected]> fix(example): Change hostname in docker multiple env examples (#70105)  Update the docker with multiple env examples by the correct hostname. I am verry happy when I see this example, I need to deploy a project with multiple environments, I tested current example for my machine, but it started but it didn't connect to app. I really try this example https://github.com/vercel/next.js/tree/canary/examples/with-docker-multi-env. but it doesn't connect to nextjs container because the hostname configuation is incorrect. I created this PR to change hostname from host ```localhost``` to ```0.0.0.0``` in docker with multiple environments Closes NEXT- No fixing any issues Co-authored-by: JJ Kasper <[email protected]> fix: updated typescript types for React API's (#70410)  This adds and updates some Typescript types for the React libraries used by Next.js. As a result some of the code was modified to match. Fix type error from merge (#70481) x-ref: #70410 x-ref: #70435 Ensure validator is included in vendored AMP validator (#70482) This aims to provide more stability so we aren't hitting the network to grab the validator more than we need to and instead leverage the one from build instead which should also reduce some test flakiness we've been seeing. v15.0.0-canary.169 Updated the example of with-draft-js to utilize the App Router. (#70045) This PR updates the with-draft-js example for using the App Router. Here are the changes that have been made: - Renamed the "pages" folder to the "app" folder. - Added the layout.tsx file as part of the App Router. - Updated the package.json file. CC: @samcx --------- Co-authored-by: Sam Ko <[email protected]> v15.0.0-canary.170 [Breaking] Update Dynamic APIs to be async (#68812) Next.js has a number of dynamic APIs that aren't available during prerendering. What happens when you access these APIs might differ depending on the mode you are using, for instance if you have PPR turned on or the newly introduced `dynamicIO` experimental mode. But regardless of the mode the underlying API represents accessing something that might only be available at render time (dynamic rendering) rather than prerender time (build and revalidate rendering) Unfortunately our current dynamic APIs make certain kinds of modeling tricky because they are all synchronous. For instance if we wanted to add a feature to Next.js where we started a dynamic render before a Request even hits the server it would be interesting to be able to start working on everything that does not rely on any dynamic data and then once a real Request arrives we can continue the render and provide the associated Request context through our dynamic APIs. If our dynamic APIs were all async we could build something like this because they represnt a value that will eventually resolve to some Request value. This PR updates most existing dynamic APIs to be async rather than sync. This is a breaking change and will need to be paired with codemods to realistically adopt. Additionally since this change is so invasive I have implemented it in a way to maximize backward compatibility by still allowing most synchronous access. The combination of codemods, typescript updates, and backward compat functionality should make it possible for projects to upgrade to the latest version with minimal effort and then follow up with a complete conversion over time. `cookies()` now returns `Promise<ReadonlyRequestCookies>`. Synchronous access to the underlying RequestCookies object is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Server Component const token = (await cookies()).get('token') // sync Server Component import { use } from 'react' //... const token = use(cookies()).get('token') // ------------ temporarily allowed usage // javascript, dev warning at runtime const token = cookies().get('token') // typescript, dev warning at runtime import { type UnsafeUnwrappedCookies } from 'next/headers' // ... const token = (cookies() as unknown as UnsafeUnwrappedCookies).get('token') ``` `headers()` now returns `Promise<ReadonlyHeaders>`. Synchronous access to the underlying Headers object is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Server Component const header = (await headers()).get('x-foo') // sync Server Component import { use } from 'react' //... const header = use(headers()).get('x-foo') // ------------ temporarily allowed usage // javascript, dev warning at runtime const header = headers().get('x-foo') // typescript, dev warning at runtime import { type UnsafeUnwrappedHeaders } from 'next/headers' // ... const header = (headers() as unknown as UnsafeUnwrappedHeaders).get('x-foo') ``` `draftMode()` now returns `Promise<DraftMode>`. Synchronous access to the underlying DraftMode object is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Server Component if ((await draftMode()).isEnabled) { ... } // sync Server Component import { use } from 'react' //... if (use(draftMode()).isEnabled) { ... } // ------------ temporarily allowed usage // javascript, dev warning at runtime if (draftMode().isEnabled) { ... } // typescript, dev warning at runtime import { type UnsafeUnwrappedDraftMode} from 'next/headers' // ... if ((draftMode() as unknown as UnsafeUnwrappedDraftMode).isEnabled) { ... } ``` `searchParams` is now a `Promise<{...}>`. Synchronous access to the underlying search params is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Page Component export default async function Page({ searchParams }: { searchParams: Promise<{ foo: string }> }) { const fooSearchParam = (await searchParams).foo } // sync Page Component import { use } from 'react' export default function Page({ searchParams }: { searchParams: Promise<{ foo: string }> }) { const fooSearchParam = use(searchParams).foo } // ------------ temporarily allowed usage // javascript, dev warning at runtime export default async function Page({ searchParams}) { const fooSearchParam = searchParams.foo } // typescript, dev warning at runtime import { type UnsafeUnwrappedSearchParams } from 'next/server' export default async function Page({ searchParams }: { searchParams: Promise<{ foo: string }> }) { const syncSearchParams = (searchParams as unknown as UnsafeUnwrappedSearchParams<typeof searchParams>) const fooSearchParam = syncSearchParams.foo } ``` `params` is now a `Promise<{...}>`. Synchronous access to the underlying params is still supported to facilitate migration. It should be noted that while params are not usually dynamic there are certain modes where they can be such as fallback prerenders for PPR. ```tsx // ------------ preferred usage // async Segment Component export default async function Layout({ params }: { params: Promise<{ foo: string }> }) { const fooParam = (await params).foo } // sync Segment Component import { use } from 'react' export default function Layout({ params }: { params: Promise<{ foo: string }> }) { const fooParam = use(params).foo } // ------------ temporarily allowed usage // javascript, dev warning at runtime export default async function Layout({ params}) { const fooParam = params.foo } // typescript, dev warning at runtime import { type UnsafeUnwrappedParams } from 'next/headers' export default async function Layout({ params }: { params: Promise<{ foo: string }> }) { const syncParams = (params as unknown as UnsafeUnwrappedParams<typeof params>) const fooSearchParam = syncParams.foo } ``` When using typescript with Next.js currently it is up to you to author types for Pages, Layouts and other Segment components that recieve props like `params` and `searchParams`. Next comes with some build-time type checking to ensure you have not improperly typed various top level module exports however the current type assertions for `params` and `searchParams` is `any`. This isn't very helpful because it allows you to erroneously type these props. `searchParams` is tricky because while the default type is a dictionary object parsed using node.js url parsing it is possible to customize when running a custom Next.js server. However we can ensure that you correctly type the prop as a Promise so with this change the validated type for `searchParams` will be `Promise<any>`. In the long run we will look at updating the `searchParams` underlying type to be URLSearchParams so we can move away from supporting customized parsing during rendering and we can get even more explicit about valid types. `params` is more straight forward because the framework controls the actual `params` prop implementation and no customization is possible. In the long run we want to enforce you are only typing params that are valid for the Layout level your file is located in but for now we are updating the allowed type to be `Promise<{[key: string]: string | string[] | undefined }>`. These new type restrictions may also require fixes before being able to successfully build a project that updates to include these breaking changes. These changes will also not always be codemodable because it is valid to type the entire component using an opaque type like `Props` which our codemods may not have an ability to introspect or modify. v15.0.0-canary.171 Base JS runtime for builds (#70169) fix failing ppr deploy test (#70491) This behavior is differing when deployed causing failures. [x-ref](https://github.com/vercel/next.js/actions/runs/11042054253/attempts/2) [x-ref](https://github.com/vercel/next.js/actions/runs/11041870219/attempts/2) chore(sass): add docs for `implementation` property in `sassOptions` and update `sassOption` types (#70428) We currently don't document the `implementation` property for `sassOptions`. Since this is one our maintained properties, we should also update the types for `sassOptions`. - Fixes #70020 --------- Co-authored-by: Zack Tanner <[email protected]> Co-authored-by: JJ Kasper <[email protected]> perf(turbopack): Optimize turbopack tree shaking using `pure` (#70433) Use `pure` property to check if we need a group To reduce the number of internal parts. codemod(turbopack): Remove unused async function modifier keywords (#70474) I left a bunch of these behind in #70412 . This cleans them up. The only remaining work after this is removing unused `Result<...>`s from return types. ast-grep config: ```yaml language: rust id: remove_unused_async_keyword rule: pattern: async inside: kind: function_modifiers inside: kind: function_item follows: pattern: context: | #[turbo_tasks::function] selector: attribute_item stopBy: not: kind: attribute_item has: field: body not: has: any: - kind: await_expression - pattern: context: foo!($$$ await $$$) selector: token_tree inside: kind: macro_invocation stopBy: end stopBy: any: - kind: function_item - kind: async_block - kind: closure_expression fix: "" ignores: - "**/turbo-tasks-testing/**" - "**/turbo-tasks-memory/tests/**" ``` Applied with: ``` sg scan -U -r ../codemod_remove_unused_async_keyword.yml . && cargo fmt ``` docs(cli): add mention of default port with experimental-https (#70497) There is no mention of what the default port is when you `next dev --experimental-https`. x-ref: https://x.com/rauchg/status/1839092783392632867 --------- Co-authored-by: Will Binns-Smith <[email protected]> remove redux devtools from router reducer (#70495) It's a bit odd that we expose this internal debugging capability in production and it seems to cause potential production issues when serializing unsupported data structures ([x-ref ](#69436)) If we feel a need to re-introduce the ability to introspect on the router state even in production we could consider relanding it in an opt-in way, and not run on every action. But I think since we've moved away from throwing promises in reducers (back when the reducers could potentially be replayed by React, in early Suspense implementations), I'm not sure this provides as much value. Fixes #70441 feat(turbopack): Evaluate simple numeric addition (#70273) Add evaluation logic for cases where we are sure that the result is a number and not a string. It's required for DCE. Upgrade React from `5d19e1c8-20240923` to `778e1ed2-20240926` (#70486) codemod(turbopack): Remove unused `Result<...>` return types from `#[turbo_task::function]`s (#70492) The `#[turbo_tasks::function]` macro always exposes a `impl Future<Output = Result<ReadRef<T>>>`, regardless of the function's actual return type. We only need to use a `Result<...>` return type when the function can fail. If it's infallible, this just adds noise. I left a bunch of these behind in #70412, plus I think we had a lot of these independent of that PR. This cleans them up. ```yaml language: rust id: remove_unused_result_return_type utils: last-expression-inside-block: any: - inside: # single-line blocks just have the expression as the only child kind: block nthChild: position: 1 reverse: true - inside: # multi-line blocks wrap their final expression in an expression_statement kind: expression_statement inside: kind: block nthChild: position: 1 reverse: true ok-expression: kind: call_expression any: - pattern: Ok($_ARG) - pattern: $$$::Ok($_ARG) ok-expression-capturing: kind: call_expression any: - pattern: Ok($ARG) - pattern: $$$::Ok($ARG) # ast-grep does not appear to allow utils to be recursive, split out "simple blocks", and limit supported nesting simple-block-with-implicit-ok-return: kind: block has: nthChild: position: 1 reverse: true matches: ok-expression simple-expression-ok-value: any: - matches: simple-block-with-implicit-ok-return - kind: if_expression all: - has: field: consequence matches: simple-block-with-implicit-ok-return - has: field: alternative has: matches: simple-block-with-implicit-ok-return - kind: match_expression has: field: body not: has: kind: match_arm has: field: value not: any: - matches: ok-expression - matches: simple-block-with-implicit-ok-return block-with-implicit-ok-return: any: - matches: simple-block-with-implicit-ok-return - kind: block has: nthChild: position: 1 reverse: true any: - kind: expression_statement has: matches: simple-expression-ok-value - matches: simple-expression-ok-value # single-line blocks don't result-return-type: pattern: context: fn func() -> Result<$INNER_RET_TY> {} selector: generic_type infallible-fn: # this function only appears to return `Ok(...)`, it does not use try_expression (`?`) or `anyhow::bail!(...)` kind: function_item not: has: field: body any: - not: matches: block-with-implicit-ok-return - has: stopBy: kind: function_item any: - kind: try_expression - pattern: "?" inside: kind: macro_invocation stopBy: end - pattern: bail!($$$) - pattern: $$$::bail!($$$) - kind: return_expression not: has: matches: ok-expression rule: all: - pattern: $FUNC - kind: function_item has: field: return_type matches: result-return-type follows: pattern: context: | #[turbo_tasks::function] selector: attribute_item stopBy: not: kind: attribute_item - matches: infallible-fn rewriters: # this rewriter is far from perfect, and might rewrite too much - id: rewrite-return-type rule: matches: result-return-type inside: kind: function_item field: return_type fix: $INNER_RET_TY - id: unwrap-ok-values rule: all: - matches: ok-expression-capturing - any: - matches: last-expression-inside-block - inside: kind: return_expression - inside: kind: match_arm fix: $ARG transform: NEW_FUNC: rewrite: rewriters: - rewrite-return-type - unwrap-ok-values source: $FUNC fix: $NEW_FUNC ignores: - "**/turbo-tasks-testing/**" - "**/turbo-tasks-memory/tests/**" ``` ``` sg scan -U -r ../codemod_remove_unused_result_return_type.yml && cargo fix --lib --allow-dirty && cargo fmt ``` I used `cargo fix` in this case to auto-remove the now-unused `anyhow::Result` imports. I manually fixed clippy lints that now violated the `let_and_return` lint rule (using a separate commit inside this PR), as `cargo clippy --fix` seemed to hang when processing our `build.rs` files? Sitemap video tag support (#69349) Co-authored-by: Sam Ko <[email protected]> Co-authored-by: Jiachi Liu <[email protected]> Respect reexports from metadata API routes (#70508) Move ci-info utility to be under the server folder (#70514) This is because CI info will be used by other modules of the server, not just Telemetry. This refactoring doesn't change any functionalities. Use Server/Client Manifests from Singleton in encryption-utils (#70485) The closure encryption utilities need the same module maps as use-cache-wrapper. We can share the same singletons. Using singletons for this is sketchy because if concurrent requests switches to another page with a different manifest, it would potentially have missing entries. We should ideally use AsyncLocalStorage but this is not making anything worse and any solution should apply to both. This doesn't actually make anything new work. Because you can't pass a Server References into these functions since React doesn't yet allow Server References inside the RSC layer to be encoded through encodeReply. We could. One thing to note there is that if we do allow that then the id of the Server Reference ideally includes the hash of its implementation (not just Cache IDs) because if the implementation can change without the id then passing a Server Reference as an argument to "use cache" and calling it within the cache should not reuse results if the implementation changes. It also doesn't yet work to pass Client References out of these functions because the SSR manifest is missing. That is already missing for encryption too and we should pass the same thing into both there. This clarifies that in either case we should always pass null for moduleLoading because that's only used for SSR and would lead to unnecessary preloads to be added if we replayed the preloads that are already covered by client references. refactor: remove ability to call getStaticPaths from app directory pages (#70477) We previously supported a legacy mode of exporting a `getStaticPaths` from app directory pages. This removes that option in favour of `generateStaticParams`. Turbopack build: Add devlow-bench (#70511) Ensures Webpack build and Turbopack build results for the heavy-npm-deps benchmark are uploaded to DataDog so that we can track them over time.  refactor: extracted zod configuration (#70478)  This just moves the zod helper utilities into it's own file so we can re-use it in future PR's. [ppr] Added fallback shell debugging (#70528) This enhances the experimental debugging mode for Partial Fallback Prerendering to only render the fallback shell. Remove shouldRevalidateStale concept from CacheHandlers (#70493) We want to immediately expire any stale entries from memory caches. So we just have treat them as missing/expired directly. fallback shell should not error when dynamic due to params access even with dynamic = "error" (#70534) When producing a fallback shell params is dynamic. Normally anything dynamic shoudl be a build error when `export const dynamic = "error"` is used. however for fallback shells we'll never have fully static shells, nor should we since the whole point is to produce a PPR shell that server a wide range of paths. In the refactor for async dynamic APIs I introduced a bug where fallback param dynamic also errored if `export const dynamic = "error"` was used. This change corrects this behavior and adds a corresponding test Add cache scope handling for dynamic IO for dev/build (#70408) As discussed this adds an in memory cache scope which is leveraged for seeding during prefetch and then leveraged during non-prefetch requests in development and during build it shares a cache scope across one build worker. During production server mode the cache scopes are specific per-request with no prefetch cache seeding. remove unimplemented onError errorInfo argument (#70531) RSC has never supported the `errorInfo` argument to `onError` unlike SSR. This PR updates our usage of onError in RSC contexts to clarify that this value does not exist This also updates the next interned types for react-dom/server to reflect that `renderTo...` and `prerender` support the `ErrorInfo` second arg and `resume` does not. Disable React 18 tests on PRs (#70541) New CI budget is not approved yet and the hydration tests are flaky. There's no active work on Pages router so this is safe-ish to ignore to unblock work on App router which doesn't run on the installed React anyway. Add env for setting cache handler path (#70537) As discussed this allows customizing the cache handler via env instead of only in `next.config`. Disable "use cache" outside of dynamicIO (#70538) Include buildId in the cache breaker until we have hashed Action IDs (#70542) Currently our Action IDs don't include hashing of the implementation which they ideally should, or at least have a separate ID for that. This means it is not safe to reuse cache entries across deployments since the Action ID can remain unchanged. For now we include the build ID as part of the cache key to ensure we don't use cache entries. We should remove this or replace it with the hash of the Action later. Support dynamicIO in middlware routes and generateStaticParams (#70544) route.ts files (and other routes like metadata routes) still need dynamicIO semantics when runnign in edge runtime. This change adds support for configuring dynamicIO for edge routes. It is hard to test properly because edge routes never statically generate and at the moment there are no other observable semantics. If we introduce new semantics that are distinct for dynamicIO that affect dynamic rendering we should update these tests to assert them. Similarly generateStaticParams also needs dynamicIO semantics when configured. Right now it's not quite possible to assert this because there are no observable semantics. We should have one which is that fetchCache is not configurable with dynamicIO on however that isn't implemented yet. This change adds tests but they will need to be updated once we update the fetchCache behavior Unwrap `createServerReference`, and pass additional parameters (#69190) For facebook/react#30741 This PR adds several additional parameters to the `createServerReference` calls generated by the Server Reference SWC transform, to later enable React to map server actions that are imported into client components back to their server locations (dev mode only). Currently the inner `findSourceMapURL` function is not yet implemented. In a follow-up we will unwrap `registerServerReference` as well, which is needed for server actions in the react server layer. --------- Co-authored-by: Hendrik Liebau <[email protected]> Turbopack build: Fix benchmark running with webpack (#70533) Ensures there is no error running Tailwind with webpack in this benchmark.  uncomment test try test try test test: try package json remove temp try cli as before rc and transform path use process cwd run for change try cwd to packages try cna path try get pkg fix: path itg test.. try try e2e dep skip currnet testdir cwd exist sync? ? readdir dirent string lfg test: expected tests test: delete e2e try #70592 resolve conflict with canary Revert "resolve conflict with canary" This reverts commit 43d71ae. Revert "try #70592" This reverts commit 2637d43.

…and update `sassOption` types (vercel#70428) ## Why? We currently don't document the `implementation` property for `sassOptions`. Since this is one our maintained properties, we should also update the types for `sassOptions`. - Fixes vercel#70020 --------- Co-authored-by: Zack Tanner <[email protected]> Co-authored-by: JJ Kasper <[email protected]>

rtritto · 2024-10-01T15:39:31Z

@samcx with 15.0.0-canary.174 this issue still persists with:

// next.config
  sassOptions: {
    implementation: 'sass-embedded'
  },

sass-embedded isn't added to peer dependencies and to peer dependencies meta.

On build step, I got this error:

To use Next.js' built-in Sass support, you first need to install `sass`.
Run `npm i sass` or `yarn add sass` inside your workspace.
Learn more: https://nextjs.org/docs/messages/install-sass

#70428 (comment) changes are missing.

Please can you reopen this issue?

FYI @ijjk

samcx · 2024-10-02T19:15:27Z

@rtritto Can you clarify what needed to be updated exactly?

I'm also not getting that issue.

rtritto · 2024-10-02T20:27:19Z

@samcx To reproduce, you need to import a file .scss in the /pages/_app and then start.

TODOs:

fix the support of sass-embedd (no error message on logs)
update the error message on logs with sass and sass-embedd and not only sass:

update the documentation (https://nextjs.org/docs/messages/install-sass) with the reference(s) to sass-embedded and not only sass
add sass-embedded to peer dependencies and peer dependencies meta

samcx · 2024-10-02T21:48:22Z

@rtritto Not seeing this issue with Pages Router as well.

rtritto · 2024-10-04T11:07:54Z

@samcx

  ▲ Next.js 15.0.0-canary.177
  - Local:        http://localhost:3000
  - Environments: .env.development, .env

 ✓ Starting...
 ✓ Ready in 1622ms
 ○ Compiling / ...
 ⨯ ./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/build/webpack/loaders/css-loader/src/index.js??ruleSet[1].rules[13].oneOf[13].use[1]!./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/build/webpack/loaders/postcss-loader/src/index.js??ruleSet[1].rules[13].oneOf[13].use[2]!./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/build/webpack/loaders/resolve-url-loader/index.js??ruleSet[1].rules[13].oneOf[13].use[3]!./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/compiled/sass-loader/cjs.js??ruleSet[1].rules[13].oneOf[13].use[4]!./scss/videojs.scss
Error: next tried to access sass (a peer dependency) but it isn't provided by its ancestors; this makes the require call ambiguous and unsound.

Required package: sass
Required by: next@virtual:0f3ca8e0ef6d2a24cc5dafda1de20914dbbc7bd5ab1c182de4414ffb141d3021fe4045bc036f82d6b7804d5facc1b46ed6da48a16ca8d1f61c1c14997edde76f#npm:15.0.0-canary.177 (via C:\test-sass-embedded\.yarn\__virtual__\next-virtual-865f8a5342\4\Users\<USER>\AppData\Local\Yarn\Berry\cache\next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip\node_modules\next\dist\compiled\sass-loader\)

Ancestor breaking the chain: test-sass-embedded@workspace:.

Require stack:
- C:\test-sass-embedded\.yarn\__virtual__\next-virtual-865f8a5342\4\Users\<USER>\AppData\Local\Yarn\Berry\cache\next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip\node_modules\next\dist\compiled\sass-loader\cjs.js
- C:\test-sass-embedded\.yarn\__virtual__\next-virtual-865f8a5342\4\Users\<USER>\AppData\Local\Yarn\Berry\cache\next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip\node_modules\next\dist\compiled\loader-runner\LoaderRunner.js
- C:\test-sass-embedded\.yarn\__virtual__\next-virtual-865f8a5342\4\Users\<USER>\AppData\Local\Yarn\Berry\cache\next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip\node_modules\next\dist\compiled\webpack\bundle5.js
- C:\test-sass-embedded\.yarn\__virtual__\next-virtual-865f8a5342\4\Users\<USER>\AppData\Local\Yarn\Berry\cache\next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip\node_modules\next\dist\compiled\webpack\webpack.js
- C:\test-sass-embedded\.yarn\__virtual__\next-virtual-865f8a5342\4\Users\<USER>\AppData\Local\Yarn\Berry\cache\next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip\node_modules\next\dist\server\config-utils.js
- C:\test-sass-embedded\.yarn\__virtual__\next-virtual-865f8a5342\4\Users\<USER>\AppData\Local\Yarn\Berry\cache\next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip\node_modules\next\dist\server\config.js
- C:\test-sass-embedded\.yarn\__virtual__\next-virtual-865f8a5342\4\Users\<USER>\AppData\Local\Yarn\Berry\cache\next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip\node_modules\next\dist\server\next.js
- C:\test-sass-embedded\.yarn\__virtual__\next-virtual-865f8a5342\4\Users\<USER>\AppData\Local\Yarn\Berry\cache\next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip\node_modules\next\dist\server\lib\start-server.js
Import trace for requested module:
./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/build/webpack/loaders/css-loader/src/index.js??ruleSet[1].rules[13].oneOf[13].use[1]!./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/build/webpack/loaders/postcss-loader/src/index.js??ruleSet[1].rules[13].oneOf[13].use[2]!./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/build/webpack/loaders/resolve-url-loader/index.js??ruleSet[1].rules[13].oneOf[13].use[3]!./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/compiled/sass-loader/cjs.js??ruleSet[1].rules[13].oneOf[13].use[4]!./scss/videojs.scss
./scss/videojs.scss
 ⨯ ./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/build/webpack/loaders/css-loader/src/index.js??ruleSet[1].rules[13].oneOf[13].use[1]!./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/build/webpack/loaders/postcss-loader/src/index.js??ruleSet[1].rules[13].oneOf[13].use[2]!./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/build/webpack/loaders/resolve-url-loader/index.js??ruleSet[1].rules[13].oneOf[13].use[3]!./.yarn/__virtual__/next-virtual-865f8a5342/4/Users/<USER>/AppData/Local/Yarn/Berry/cache/next-npm-15.0.0-canary.177-dceb92e7a3-10c0.zip/node_modules/next/dist/compiled/sass-loader/cjs.js??ruleSet[1].rules[13].oneOf[13].use[4]!./scss/videojs.scss
Error: next tried to access sass (a peer dependency) but it isn't provided by its ancestors; this makes the require call ambiguous and unsound.

samcx · 2024-10-04T16:39:56Z

@rtritto Can you also try testing with a different package manager?

rtritto · 2024-10-04T18:14:59Z

@samcx it works with node-modules as node linker.
The issue is on build step (next build) and with PnP (Plug'n'Play) node linker (pnp).
Using yarn, I get the error above.
Using pnpm with PnP enabled (node-linker=pnp in .npmrc), I get:

.pnp.cjs:12111
    throw firstError;
    ^

Error: Your application tried to access styled-jsx, but it isn't declared in your dependencies; this makes the require call ambiguous and unsound.

Required package: styled-jsx (via "styled-jsx\package.json")
Required by: C:\test-sass-embedded\node_modules\.pnpm\[email protected][email protected][email protected]_zqnbduqtthmjkjjqbxyqbncgsa\node_modules\next\dist\server\

Require stack:
- C:\test-sass-embedded\node_modules\.pnpm\[email protected][email protected][email protected]_zqnbduqtthmjkjjqbxyqbncgsa\node_modules\next\dist\server\require-hook.js
- C:\test-sass-embedded\node_modules\.pnpm\[email protected][email protected][email protected]_zqnbduqtthmjkjjqbxyqbncgsa\node_modules\next\dist\bin\next
    at require$$0.Module._resolveFilename (C:\test-sass-embedded\.pnp.cjs:12110:13)
    at resolve (node:internal/modules/helpers:145:19)
    at Object.<anonymous> (C:\test-sass-embedded\node_modules\.pnpm\[email protected][email protected][email protected]_zqnbduqtthmjkjjqbxyqbncgsa\node_modules\next\dist\server\require-hook.js:38:32)
    at Module._compile (node:internal/modules/cjs/loader:1546:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1691:10)
    at require$$0.Module._extensions..js (C:\test-sass-embedded\.pnp.cjs:12153:33)
    at Module.load (node:internal/modules/cjs/loader:1317:32)
    at Module._load (node:internal/modules/cjs/loader:1127:12)
    at require$$0.Module._load (C:\test-sass-embedded\.pnp.cjs:12001:31)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)

Node.js v22.9.0

To fix, the first step is the point 4. (title of this issue) of TODOs.
Next you should check/fix the use of sass-embedded in the code.

github-actions · 2024-10-19T00:05:07Z

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

rtritto added the bug Issue was opened via the bug report template. label Sep 12, 2024

github-actions bot added create-next-app Related to our CLI tool for quickly starting a new Next.js application. Runtime Related to Node.js or Edge Runtime with Next.js. Webpack Related to Webpack with Next.js. labels Sep 12, 2024

samcx mentioned this issue Sep 24, 2024

chore(sass): add docs for implementation property in sassOptions and update sassOption types #70428

Merged

ijjk closed this as completed in #70428 Sep 26, 2024

github-actions bot added the locked label Oct 19, 2024

github-actions bot locked as resolved and limited conversation to collaborators Oct 19, 2024

samcx reopened this Oct 21, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Missing `sass-embedded` peer dependency #70020

Missing `sass-embedded` peer dependency #70020

rtritto commented Sep 12, 2024 •

edited

Loading

samcx commented Sep 24, 2024

rtritto commented Oct 1, 2024 •

edited

Loading

samcx commented Oct 2, 2024

rtritto commented Oct 2, 2024 •

edited

Loading

samcx commented Oct 2, 2024

rtritto commented Oct 4, 2024 •

edited

Loading

samcx commented Oct 4, 2024

rtritto commented Oct 4, 2024 •

edited

Loading

github-actions bot commented Oct 19, 2024

Missing sass-embedded peer dependency #70020

Missing sass-embedded peer dependency #70020

Comments

rtritto commented Sep 12, 2024 • edited Loading

Link to the code that reproduces this issue

To Reproduce

Current vs. Expected behavior

Current

Expected:

Provide environment information

Which area(s) are affected? (Select all that apply)

Which stage(s) are affected? (Select all that apply)

Additional context

samcx commented Sep 24, 2024

rtritto commented Oct 1, 2024 • edited Loading

samcx commented Oct 2, 2024

rtritto commented Oct 2, 2024 • edited Loading

samcx commented Oct 2, 2024

rtritto commented Oct 4, 2024 • edited Loading

samcx commented Oct 4, 2024

rtritto commented Oct 4, 2024 • edited Loading

github-actions bot commented Oct 19, 2024

Missing `sass-embedded` peer dependency #70020

Missing `sass-embedded` peer dependency #70020

rtritto commented Sep 12, 2024 •

edited

Loading

rtritto commented Oct 1, 2024 •

edited

Loading

rtritto commented Oct 2, 2024 •

edited

Loading

rtritto commented Oct 4, 2024 •

edited

Loading

rtritto commented Oct 4, 2024 •

edited

Loading