:) ни чего не нашёл про это путного но зато , научился запускать бек и фронт отдельно на время разработки через прокси :) это уже удобно ...

но с маршрутизаций как то надо быть

По хорошему до сервера на спринге вообще не должны доходить запросы ангуляр-роутера. Обычно делают 2 модуля: один - чисто сервер, второй - чисто фронт на ангуляре. На продакшене какой-нибудь nginx проксирует к бэку ТОЛЬКО запросы, совпадающие с определенным паттерном, например /api/**. Все остальные запросы отдают index.html либо статику, если файл существует. Т.е. "трик с 404" делается уже средствами nginx.

Чтобы так же работало и на localhost, можно например запускать gulp, в котором настроить любой node.js реверс-прокси, например browserSync. Который будет действовать по такому же принципу, как nginx. Запускать его параллельно серверу и в таком режиме девелопить. В браузере открывать не localhost:8080, а localhost:3000 (или какой там порт будет node.js слушать).

Можно, наверное, и в самом сервере добавить контроллер, который будет слушать /** и отдавать всегда index.html на любой запрос (если конечно он не перекроет все /api** контроллеры. Но это такое себе решение. Серверу с API незачем знать, что перед ним еще ангуляр или react или кто-то там еще.

ну так вадь удобно запустить -jar на сервере и не парится , и я видел как это работает иделально. Понимаю что можно запустить всё отдельно ... но это может и правильно но не удобно для моего случая ... нужно максимально упростить развёртывание. Тоесть одна jar ка

не знаю как в ангуляре, но во вью и реакте генерится окончтельный js файл, который ты просто подключаешь на свой index.html

и ничего отдельно запускать не надо

отдельно можно запустить дев сервер, для удобства разработки

Даже если это одна jar-ка, обычно все равно перед ней стоит какой-нибудь реверс-прокси вроде nginx. И он все и делает.

А чтобы работало в том числе и без него, можно реализовать и 2е решение внутри самого приложения (404 или requestHandler на /**, отдающий index.html), которое будет прокать, если все таки запустили без nginx.

а как быть если я деплою не корень ? https://domen.com/app

Это не имеет ниакого отношения к клиент-сайд роутингу. Тут у человека проблема именно с ним, а не с тем, как именно это в бандл собирается.

приходится прописывать Base url для продакшена

наверху было написано, что неудобно деплоить отдельно бэк и фронт, именно это сообщение я процетировал и на него ответил

Ну это уже особенности ангуляра. Мне тоже необходимость base url не нравится, но что поделать. Если приложение все равно сервится спрингом, то можно например index.html сделать шаблоном, где этот baseUrl заполнять в момент отдачи ответа.

и у меня все таки так и остался вопрос, если вспринг секьюрити имплементится кастомный аутентификейшен провайдер, может ли это повлиять на hasRole/hasAuthority параметры http security?

по идее нет, ведь он только аутентифицирует. за авторизацию он не отвечает.

По этому коду у вас по идее роль TEST будет требоваться только если пойти на URL /test/foo, /test/bar, но не /test/foo/bar.

тогда не понимаю, почему не применяются эти параметры, у меня есть кастомный провайдер и в нем пользователю добавляется роль отличная от заданной для конкретного урл, но все равно пользователь имеет доступ к этому урл

у мене получилось реалтзовать авторизацию на базе спринга  с интеграцией её в ангуляр , но там не так всё просто ... могу дать доступ к репозитраию на заготовку проекта

спасибо, но боюсь, что это немного другая проблема, по идее то о чем я говорю, должно из коробки работать, непонятно в чем дело

Можно попробовать для начала заинжектить в какой-нибудь контроллер Principal и вывести все его роли в лог, чтобы убедиться, что у него 100% НЕТ этой роли. А то мало ли. Может ее кто-то другой добавляет.