* Use postcss instead of ember-cli-sass
This will make it possible to work with tailwindcss.
* configure postcss to compile sass
* add "sub-app" css into app/styles tree
* pin node@14 via volta
Only used by people that use volta
* Install tailwind and autoprefixer
* Create tailwind config
* Use tailwind via postcss
* Fix: tailwind changes current styling
When adding tailwind to the bottom of app.scss we apparently
change the way the application looks. We will import
it first to make sure we don't change the current styling
of the application right now.
* Automatic import of HDS colors in tailwind
* Install @hashicorp/design-system-components
* install add-on
* setup postcss scss pipeline to include tokens css
* import add-on css
* Install ember-auto-import v2
HDS depends on v2 of ember-auto-import so we need to upgrade.
* Upgrade ember-cli-yadda
v0.6.0 of ember-cli-yadda adds configuration for webpack.
This configuration is incompatible with webpack v5
which ember-auto-import v2 is using.
We need to upgrade ember-cli-yadda to the latest
version that fixes this incompatability with auto-import v2
* Install ember-flight-icons
HDS components are using the addon internally.
* Document HDS usage in engineering docs
* Upgrade ember-cli-api-double
* fix new linting errors
* ui: use environment variable for feature flagging peers
* Add documentation for `features`-service
* Allow setting feature flag for peers via bookmarklet
* don't use features service for flagging peers
* add ability for checking if peers feature is enabled
* Use abilities to conditionally use peers feature
* Remove unused features service
* Add some less fake API data
* Rename the models class so as to not be confused with JS Proxies
* Rearrange routlets slightly and add some initial outletFor tests
* Move away from a MeshChecks computed property and just use a helper
* Just use ServiceChecks for healthiness filtering for the moment
* Make TProxy cookie configurable
* Amend exposed paths and upstreams so they know about meta AND proxy
* Slight bit of TaggedAddresses refactor while I was checking for `meta` etc
* Document CONSUL_TPROXY_ENABLE
Attempt to document out what a beginner to the project needs to know here in order to get started quickly
Co-authored-by: Jared Kirschner <85913323+jkirschner-hashicorp@users.noreply.github.com>
The default namespace, and the tokens default namespace (or its origin namespace) is slightly more complicated than other things we deal with in the UI, there's plenty of info/docs on this that I've added in this PR.
Previously:
When a namespace was not specified in the URL, we used to default to the default namespace. When you logged in using a token we automatically forward you the namespace URL that your token originates from, so you are then using the namespace for your token by default. You can of course then edit the URL to remove the namespace portion, or perhaps revisit the UI at the root path with you token already set. In these latter cases we would show you information from the default namespace. So if you had no namespace segment/portion in the URL, we would assume default, perform actions against the default namespace and highlight the default namespace in the namespace selector menu. If you wanted to perform actions in your tokens origin namespace you would have to manually select it from the namespace selector menu.
This PR:
Now, when you have no namespace segment/portion in the URL, we use the token's origin namespace instead (and if you don't have a token, we then use the default namespace like it was previously)
Notes/thoughts:
I originally thought we were showing an incorrectly selected namespace in the namespace selector, but it also matched up with what we were doing with the API, so it was in fact correct. The issue was more that we weren't selecting the origin namespace of the token for the user when a namespace segment was omitted from the URL. Seeing as we automatically forward you to the tokens origin namespace when you log in, and we were correctly showing the namespace we were acting on when you had no namespace segment in the URL (in the previous case default), I'm not entirely sure how much of an issue this actually was.
This characteristic of namespace+token+namespace is a little weird and its easy to miss a subtlety or two so I tried to add some documentation in here for future me/someone else (including some in depth code comment around one of the API endpoints where this is very subtle and very hard to miss). I'm not the greatest at words, so would be great to get some edits there if it doesn't seem clear to folks.
The fact that we used to save your previous datacenter and namespace into local storage for reasons also meant the interaction here was slightly more complicated than it needed to be, so whilst we were here we rejigged things slightly to satisfy said reasons still but not use local storage (we try and grab the info from higher up). A lot of the related code here is from before we had our Routlets which I think could probably make all of this a lot less complicated, but I didn't want to do a wholesale replacement in this PR, we can save that for a separate PR on its own at some point.
This commit adds a couple of debug utilities to help us to continue slowly adding i18n support:
- We've added a CONSUL_INTL_DEBUG env/cookie variable to turn off variable interpolation within the t helper so you can see which variables are being interpolated.
- We've added a CONSUL_INTL_LOCALE env/cookie which currently supports two 'pseudo-locales' - la-fk (fake latin) and - (just dashes) either of which will make it easier to see what has not been localized until we can add prettier rules to prevent adding any copy into templates at all. I would guess if we ever translated the app we would use this for looking at things whilst developing also - but as yet I've not adding anything for that here seeing as we don't translate anything.
Both variables are dev-time only and all code for this is removed from the production build.
* ui: Add Admin Partition feature flag
This adds a `PartitionEnabled`/`CONSUL_PARTITIONS_ENABLED` feature flag
that can be set during production form the consul binary, or
additionally during development/testing via cookies.
* Add partitions bookmarklet and docs, and all eng docs from main README to the docs instead.
You probably already have the app running once you need these, and it reduces the amount of text/detail in the main README
* Add the env variable section back into the README with actual env vars
wenincode