Move the form-level validation errors in the **project URL and slug field** to be inline on the **project creation page**. ### Design Reference | Before | After | | ------ | ------ | | {width=900 height=364} | {width=900 height=222} | ### Implementation Guide > ⚠️ _Generated with GitLab Duo as a starting point. The assignee should verify and fill in the gaps._ The goal is to replace the single generic error message on the project URL (slug) field with specific inline validation messages that identify exactly what is wrong with the input. The backend rules live in `lib/gitlab/path_regex.rb` and `app/models/project.rb` and need to be ported to the frontend. Unlike the project name field, **no equivalent `project_path_rules.js` file exists yet** — it must be created. #### 1. Create `project_path_rules.js` Create `app/assets/javascripts/projects/project_path_rules.js` as a port of the backend regex from `lib/gitlab/path_regex.rb`. The `NAMESPACE_FORMAT_REGEX_JS` constant breaks down into three distinct constraints (note: the `.git`/`.atom` suffix restriction uses a negative lookbehind not supported in all JS environments and is intentionally left to server-side validation, matching the same decision made for the group path equivalent): ```js // app/assets/javascripts/projects/project_path_rules.js import { s__ } from '~/locale'; // PATH_START_CHAR = '[a-zA-Z0-9_\.]' export const START_RULE = { regex: /^[a-zA-Z0-9_.]/, message: s__('ProjectsNew|Project slug must start with a letter, digit, underscore, or dot.'), }; // Body: PATH_START_CHAR + '[a-zA-Z0-9_\-\.]' export const CONTAINS_RULE = { regex: /^[a-zA-Z0-9_.\-]+$/, message: s__('ProjectsNew|Project slug can only contain letters, digits, underscores, dots, and dashes.'), }; // Must not end with a dash (NAMESPACE_FORMAT_REGEX_JS ends with '[a-zA-Z0-9_\-]|[a-zA-Z0-9_]') export const END_RULE = { regex: /[a-zA-Z0-9_]$/, message: s__('ProjectsNew|Project slug must not end with a dot or a dash.'), }; export const PATH_RULES = [START_RULE, CONTAINS_RULE, END_RULE]; export const checkProjectPath = (path) => { if (!path) return ''; for (const rule of PATH_RULES) { if (!rule.regex.test(path)) return rule.message; } return ''; }; ``` > **Note:** Cross-check the exact allowed character set against `PROJECT_PATH_FORMAT_REGEX` in `lib/gitlab/path_regex.rb` — the project path regex (`PATH_REGEX_STR`) is slightly stricter than the namespace regex and does not allow a single-character path ending in a letter/digit without the middle segment. #### 2. Update `project_new.js` File: `app/assets/javascripts/projects/project_new.js` Import the new validator and add a `checkProjectPath` call inside `setProjectNamePathHandlers`, mirroring the existing `checkProjectName` pattern. Run it on every `keyup` and `change` event on `#project_path`, and also on form submit. ```js // app/assets/javascripts/projects/project_new.js import { checkProjectPath } from './project_path_rules'; const checkProjectSlug = (projectPathInput) => { const msg = checkProjectPath(projectPathInput.value); const projectPathError = document.querySelector('#js-project-path-error'); if (!projectPathError) return; if (msg) { projectPathError.innerText = msg; projectPathError.classList.remove('gl-hidden'); projectPathInput.setAttribute('aria-describedby', projectPathError.id); } else { projectPathError.classList.add('gl-hidden'); projectPathInput.removeAttribute('aria-describedby'); } projectPathInput.setAttribute('aria-invalid', Boolean(msg)); }; // Inside setProjectNamePathHandlers, extend the projectPathInputListener: const projectPathInputListener = () => { onProjectPathChange($projectNameInput, $projectPathInput, hasUserDefinedProjectName); checkProjectSlug($projectPathInput); // add this line hasUserDefinedProjectPath = $projectPathInput.value.trim().length > 0; // ... existing specialRepo toggle }; ``` Also call `checkProjectSlug` inside the `.js-create-project-button` click handler so that an invalid slug entered before JS initialised is caught on submit. #### 3. Update `_new_project_fields.html.haml` File: `app/views/projects/_new_project_fields.html.haml` Add the inline error element directly after the project slug input. Follow the same pattern as `#js-project-name-error`: ```haml .form-group.project-path.gl-col-sm-6 = f.label :path, class: 'label-bold' do %span= _("Project slug") = f.text_field :path, placeholder: "my-awesome-project", class: "form-control gl-form-input", required: true, aria: { required: true }, data: { testid: 'project-path', username: current_user.username } #js-project-path-error.gl-field-error.gl-mt-2.gl-hidden{ role: 'alert' } ``` If a help text element is added beneath the slug field in future, wire `aria-describedby` to toggle between it and the error element, matching the name field pattern. #### Known unknowns for the assignee - **Minimum path length** — `validates :path, length: { minimum: 2 }` may apply (check `app/models/project.rb` and `app/models/namespace.rb`). If so, add a `MIN_LENGTH_RULE` to `project_path_rules.js`. - **Maximum path length** — `URL_MAX_LENGTH = 255` is referenced in `lib/gitlab/path_regex.rb` (`PATH_REGEX_STR` uses it). Decide whether to add a `MAX_LENGTH_RULE` or rely on the `maxlength` HTML attribute. - **Reserved words** — `ILLEGAL_PROJECT_PATH_WORDS` (e.g. `badges`, `blob`, `tree`) are blocked server-side. These cannot be checked purely client-side without shipping the full list to the browser. Confirm the server error for reserved words is surfaced gracefully and not overwritten by the inline validator. - **OCI repository path compatibility** — `validates :path, format: { with: Gitlab::Regex.oci_repository_path_regex }` runs on `path_changed?`. Inspect `lib/gitlab/regex.rb` to understand what additional characters this rejects and whether a frontend rule is needed. - There may be additional EE-only path validations worth checking in `ee/app/models/`. #### 4. Update tests File: `spec/frontend/projects/project_new_spec.js` (or equivalent) - Slug starting with `-` → shows start-character error - Slug containing `!` → shows invalid-character error - Slug ending with `.` → shows end-character error - Slug ending with `-` → shows end-character error - Valid slug → no error shown, async availability check (if any) is triggered - Single-character slug → shows minimum length error (once rule is added) - Empty slug on submit → shows generic required message - `aria-invalid` is `true` when error is shown, `false`/absent when valid