Remove ConfigService, consolidate onto window.Craft global#19043
Draft
brianjhanson wants to merge 6 commits into
Draft
Remove ConfigService, consolidate onto window.Craft global#19043brianjhanson wants to merge 6 commits into
brianjhanson wants to merge 6 commits into
Conversation
- Remove ConfigService class entirely — window.Craft is the single source of config truth (flat object canonical) - Remove window.Cp and window.CpConfig globals - bootstrap/cp.ts reads config directly from window.Craft and attaches services ($queue, $axios) and lifecycle (booting, booted, init, start) - actionClient.ts getActionUrl/getCpUrl delegate to Craft.getActionUrl() and Craft.getCpUrl() (canonical implementations from legacy Craft.js) - Fix: actionHeaders() read Cp.registeredAssetBundles (wrong global) - Fix: apiClient.ts read Cp.apiParams/Cp.httpProxy (wrong global) - QueueService uses imported getActionUrl() instead of ConfigService - CpQueueIndicator uses imported getCpUrl() instead of ConfigService - app.blade.php: config merged onto Craft via Object.assign, head shim provides early booting/booted stubs, start() called directly - Types: CraftStatic extends CpServices, includes lifecycle and URL helpers - Add CraftConfigData DTO with #[TypeScript] for Spatie type generation - Generated types.d.ts includes full CraftConfigData type Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Introduce configure()/getCraft()/tryGetCraft() pattern so the @craftcms/cp package no longer depends on the global window.Craft object. The host application passes the context explicitly at boot via configure(). - Add craft.ts with configure(), getCraft(), tryGetCraft(), resetConfiguration() - actionClient.ts uses getCraft() lazily in request interceptor - apiClient.ts uses getCraft() lazily in request interceptor - disclosure.ts uses tryGetCraft() for optional setCookie - Export CraftContext type and configure functions from package index - bootstrap/cp.ts calls configure(window.Craft) during init() Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Undo the Spatie typescript-transformer type generation for window.Craft. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Split the monolithic @craftcms/cp package into: - @craftcms/ui: Pure UI components, translations, cookies, utilities, styles, constants, and Storybook (no HTTP/service logic) - resources/js/common/services/: QueueService, AssetIndexer, Csrf - resources/js/common/api/: actionClient, apiClient Key changes: - Package renamed from @craftcms/cp to @craftcms/ui - Services and API utilities moved to resources/js/common/ - Auth challenge form refactored to use native fetch (no actionClient dep) - Disclosure component uses Cookies class directly (no configure() needed) - Removed craft.ts configure/getCraft pattern (app layer uses window.Craft) - Queue types moved to resources/js/common/types/queue.ts - Updated all imports across 100+ files - All 193 tests pass (186 UI + 7 Queue) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The legacy CP.js no longer imports QueueService directly. Instead it reads from Craft.$queue which bootstrap/cp.ts already sets to the singleton instance. The deprecated Craft.cp methods (runQueue, trackJobProgress, setJobData, etc.) now delegate to Craft.$queue. This removes the cross-package import from craftcms-legacy into resources/js/, keeping the legacy bundle self-contained. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Move packages/craftcms-ui/src/styles/cp.css → resources/css/ui.css - Create packages/craftcms-ui/src/styles/base.css for design token imports (used by Storybook and any consumer needing just the design system) - Update resources/css/cp.css to import ./ui.css instead of package path - Update Storybook preview to use base.css - Point package styles/* export to src/ for dev-time CSS resolution - Add vitest to root devDependencies (fixes storybook addon resolution) - Update tailwind.css comments Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR addresses a bit of a larger change that's been bothering me for a bit. When we named the front end package
@craftcms/cpwe were thinking that all of the code related to the CP would be held in there. This was pre-inertia when the idea of the new CP was a bit more more fluid.Now that we've settled on inertia, it became a little difficult to draw the line of what belonged in
@craftcms/cpand what belonged in the mainresourcesfolder.This switches things up a to make that more clear.
The
@craftcms/cppackage has been renamed to@craftcms/uiand is more narrowly scoped to the web components and a handful of utilities they rely on (most notably thetfunction). I've moved the services over to the mainresources/jsfile where they're more appropriate. I don't think anyone is going to want or need to use ourQueueServiceanywhere but in our CP. it makes sense to keep it closer to the chest.This PR also clarifies the configuration story. I had originally thought we'd have some kind of
Cpexport from the@craftcms/cppackage that you would configure with data from the server, and then import and use throughout the codebase. However, for the moment, that isn't terribly feasible. We still have a lot of code that expects a globalCraftvariable to be around, and to have the configuration data tied to it. Rather than fight that uphill battle now, this moves everything back to a singlewindow.Craftvariable that can be used anywhere. This variable will likely get a few new tricks as we go along, but for the moment it's largely the way it used to be.Changes