Can UI Page Source Changes Be Tracked Individually in Git/Bitbucket?

[JoaquinG7082603]

Hi everyone,

I'm trying to understand how source control works for UI Pages that are ultimately stored in ServiceNow as a single sys_ui_page record.

My goal is to determine whether changes can be tracked at the individual source-file level (for example React, TypeScript, CSS, utility files, etc.) or whether all modifications are ultimately represented as changes to a single ServiceNow artifact.

For example, if multiple developers are working on a UI Page:

• Developer A modifies one frontend component.
• Developer B modifies a different piece of logic.
• Both developers commit their changes through Git/Bitbucket.

 

What I'm unsure about is:

1. Does Git/Bitbucket actually see those changes as separate files?
2. When the application is linked to ServiceNow Source Control, are those files stored individually in the repository or are they bundled into a single UI Page artifact? 
3. If two developers modify different parts of the same UI Page, can Git perform normal file-level diffs and merges, or does ServiceNow ultimately treat everything as a change to the same sys_ui_page record?
4. Has anyone worked with UI Pages, Now SDK, React-based experiences, or similar implementations where source control provided visibility into individual file changes instead of only record-level changes?

I'm mainly trying to understand what is actually stored in the repository and how granular the change tracking can be, rather than looking for workflow recommendations.

Thanks!

[Vikram Reddy]

Hi @JoaquinG7082603,

Look at which side is actually pushing to Git, that decides your granularity, not the sys_ui_page table itself. Your screenshot shows entries typed as UX Asset (main, main.js.map) coming through Studio's native "Link to Source Control" push, that's the webpack-bundled build output, one blob per build, not decomposed by component. A different setup gives you real file-level tracking:

• Now SDK project structure: src/client with main.tsx, components/, services/, and ui-pages/page.now.ts are actual separate files, git diffs and merges them normally before the build step ever runs
• Studio push of a built UX experience: what lands in the repo is the compiled asset (as in your screenshot), diffing minified main.js is basically useless
• Classic sys_ui_page (Jelly HTML/client script/processing script all in one record): always one record, one XML file, no sub-file splitting regardless of path

So Developer A and B only get clean concurrent diffs if they're both committing against the pre-build Now SDK source tree, not the instance's own push-to-Git output.

Thank you,
Vikram Karety
Octigo Solutions INC

[JoaquinG7082603]

Thanks for answering, that helps. Just to make sure I understood correctly.

Right now it seems my workflow is:

React/TypeScript source > Build > ServiceNow > Git

In that case, Git would only be tracking the generated UX Assets (main.js, main.js.map, ...), so I wouldn't get meaningful diffs of the original React/TypeScript components.

Are you saying that to get useful diffs, the workflow needs to be:

React/TypeScript source > Git > Build > ServiceNow ??

So the diffs are reviewed on the .tsx / .ts source files before the bundle is generated and deployed to ServiceNow?

Also, if that's the recommended approach, do you know of any documentation or examples showing how teams manage the React/TypeScript source in Git and then deploy the built assets back into ServiceNow? I'd like to understand what the end-to-end workflow looks like in practice, I'm not sure if it's an out-of-scope type of question.

Thanks once again,
Joaquin

[Vikram Reddy · Accepted solution]

Hello @JoaquinG7082603,

Yes, that second flow is the one teams actually run once they're using the ServiceNow SDK properly, and it's the pattern the SDK's own project layout assumes. This is how a typical UI Page/component project ends up structured once it's under source control:

my-app/
  src/
    fluent/            (.now.ts definitions, source of truth)
    client/
      MyComponent/
        index.tsx       (your actual React/TS source)
        styles.css
  now.config.json
  package.json
  .gitignore           (excludes /dist, /build, node_modules)

You run "now-sdk build" (npm run build), which transpiles the .tsx/.ts under src into the bundled output, and then "now-sdk install" (npm run deploy) to push that build output to the instance. Only the src tree and now.config.json get committed, the compiled bundle is regenerated every time, never hand-edited or diffed, so it doesn't belong in git at all.

That's exactly why you'd .gitignore the build directory: main.js is a derived artifact, not a source file, so tracking it in git just gives you noisy, unreviewable diffs. Your .tsx components are the only thing worth reviewing in a PR.

For a working end-to-end reference rather than a hypothetical, ServiceNow publishes sdk-examples on GitHub with a react-ui-page-ts-sample project set up this exact way (pnpm workspace, TypeScript source, build/deploy scripts), worth cloning and poking at directly.

Thank you,
Vikram Karety
Octigo Solutions INC

[JoaquinG7082603]

Hi Vikram,

Thank you for the explanation and the references.

It helped clarify several points and gave me a better direction for further investigation.

I appreciate your time and feedback.

Best regards,
Joaquín