Sitecore Saga

Subscribe
· ·

JSS Has an Expiration Date Now

Alex Lentz

Title card: JSS Has an Expiration Date Now. Content SDK post on Sitecore Saga.

Happy Halloween! Fitting day for this one, because there’s a spooky little announcement in this week’s changelog.

On October 29th Sitecore introduced an official support lifecycle for the SDKs used with XM Cloud. The headline: Content SDK 1.x is the actively supported, recommended SDK, and JSS support for XM Cloud is being phased out. The next day they shipped Content SDK 1.2 with Next.js App Router support (beta).

Read together, the message is pretty clear. New XM Cloud work goes on Content SDK, and the JSS apps we’ve all been running for years now have a clock on them.

What the lifecycle actually says

The changelog points to KB1004260 for the full details. Go read it, because the specific dates for your JSS version are what you’ll plan around. The gist:

  • Content SDK 1.x is in Active Support. New features land here.
  • JSS is moving toward end of support for XM Cloud. Expect bug fixes and security patches, not features.
  • The SDK story is now tied to the platform story. Things like Design Library and the newer Pages capabilities are being built for Content SDK first (and in some cases, only).

None of this is a surprise if you’ve been watching the repo. But having it written down with dates changes the conversation with clients. “We should migrate eventually” becomes “here’s the date support ends.”

So how much JSS are you carrying?

Before anyone can estimate a migration, you need an inventory. On our team we have head apps spread across a bunch of repos, so I threw together a quick PowerShell scan that walks a folder of repos and reports what each one is running:

# Find-JssApps.ps1 - inventory JSS vs Content SDK across a folder of repos
param([string]$Root = 'C:\src')

Get-ChildItem -Path $Root -Filter package.json -Recurse -Depth 4 -ErrorAction SilentlyContinue |
  Where-Object { $_.FullName -notmatch '\\node_modules\\' } |
  ForEach-Object {
    $pkg  = Get-Content $_.FullName -Raw | ConvertFrom-Json
    $deps = @{}
    foreach ($section in 'dependencies', 'devDependencies') {
      if ($pkg.$section) { $pkg.$section.PSObject.Properties | ForEach-Object { $deps[$_.Name] = $_.Value } }
    }

    $jss  = @($deps.Keys | Where-Object { $_ -like '@sitecore-jss/*' })
    $csdk = @($deps.Keys | Where-Object { $_ -like '@sitecore-content-sdk/*' })
    if ($jss.Count -eq 0 -and $csdk.Count -eq 0) { return }

    $appDir = Split-Path $_.FullName
    [pscustomobject]@{
      App        = Split-Path $appDir -Leaf
      SDK        = if ($csdk.Count) { 'Content SDK' } else { 'JSS' }
      Version    = if ($csdk.Count) { $deps[$csdk[0]] } else { $deps[$jss[0]] }
      Next       = $deps['next']
      Router     = if (Test-Path "$appDir\src\app" -PathType Container) { 'App' } else { 'Pages' }
      SxaPkg     = [bool]($jss | Where-Object { $_ -like '*sxa*' })
      Components = (Get-ChildItem "$appDir\src\components" -Filter *.tsx -Recurse -ErrorAction SilentlyContinue).Count
    }
  } |
  Sort-Object SDK, App |
  Format-Table -AutoSize

It’s crude, but it answers the questions that drive an estimate: which SDK, what version, which Next.js, which router and roughly how many components. The component count is a surprisingly good proxy for effort, because the per-component work (imports, field types, a few API changes) is where the time goes.

Content SDK 1.2 and the App Router

The other half of this week’s news is App Router support. It’s flagged as beta – Sitecore says the API may still change – but it’s officially supported, and it brings:

  • Server Components by default, with streaming
  • Layout nesting and dynamic segments
  • Optional Partial Pre-rendering
  • An App Router starter in xmcloud-starter-js, plus the Skatepark demo migrated to App Router as a reference

My honest take: don’t combine the two migrations. Moving from JSS to Content SDK is one project. Moving from the Pages Router to the App Router is another one – it changes how you think about data fetching and client vs server components. Doing both at once on a production site turns a few weeks into a few months, and makes every bug twice as hard to track down.

The path I’m recommending to clients:

  1. JSS to Content SDK on the Pages Router. Same routing model, so the diff is mostly SDK APIs and config. It gets you onto the supported SDK fast.
  2. Pages Router to App Router later, once it’s out of beta and you have a reason (performance, Server Components, PPR).
  3. Greenfield builds can start on the App Router today if the team is comfortable with beta – just pin your versions and read the release notes on every bump.

What I’d do this quarter

  • Run the inventory and put the results somewhere the account team can see them
  • Read KB1004260 and note the support dates for each JSS version you’re running
  • Pick one small, low-risk site as a pilot and move it to Content SDK
  • Write down what bit you on the pilot. That becomes your estimate for everything else.

JSS has been really good to this community for a long time. But it’s time to start packing.

Resources

Alex Lentz

Alex Lentz

Senior Solutions Architect at Americaneagle.com and two-time Sitecore Technology MVP. Building on Sitecore since 2013, mostly SitecoreAI and headless Next.js these days.

LinkedIn    GitHub

←
→

Keep reading