ember-upf-utils uses the shared ESLint config - #476
Conversation
|
|
||
| module('Callback functionality', () => { | ||
| test('callback is called with parsed address data', async function (assert) { | ||
| assert.expect(1); |
There was a problem hiding this comment.
why remove this? (same for other occurrences)
| import { type AutocompletionAddress } from '@upfluence/ember-upf-utils/modifiers/setup-autocomplete'; | ||
|
|
||
| const ADDRESS_COMPONENT_TYPES = [ | ||
| export const ADDRESS_COMPONENT_TYPES = [ |
There was a problem hiding this comment.
Darn, I had hoped no-one was gonna notice...
I took the easy way out because the const was unused...
So the question becomes:
- Do we want to "future-proof" and assume the array is gonna be used at some point?
- Do we remove the array and inline the type directly?
There was a problem hiding this comment.
Haha nope! we see everything :p
But it's used L18 in type AddressComponentType = (typeof ADDRESS_COMPONENT_TYPES)[number]; so is the linter lying to us?
| this.selectedIcon = this.args.icon; | ||
| this.selectedColor = this.args.color; |
There was a problem hiding this comment.
beware of this one, can you run it as a link upfluence-web and see how logo makers work? should be in the campaign setup to setup the campaign logo.
Sometimes Ember doesn't like setting up tracked in the ctor because it can have race conditions between "constructing" & "rendering" stages
…ivity-watcher tests
What does this PR do?
Migrates
ember-upf-utilsto use the shared ESLint config (@upfluence/w-conf) and fixes the resulting lint issues.Related to: #PYX-417
What are the observable changes?
No user-facing changes. The project now lints using the shared
w-confESLint flat config instead of the legacy.eslintrcsetup.🧑💻 Developer Heads Up
N/A
Good PR checklist