@barchart/portfolio-api-common 7.1.1 → 7.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.aiassistant/rules/ai.md +74 -0
- package/AGENTS.md +70 -0
- package/lib/providers/InstrumentProvider.js +64 -9
- package/package.json +1 -1
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
---
|
|
2
|
+
apply: always
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Univerzalna pravila pisanja koda (važe za svaki projekat)
|
|
6
|
+
|
|
7
|
+
Piši novi i izmenjeni kod tako da izgleda kao da je pisan u istom stilu kao postojeći kod oko njega.
|
|
8
|
+
|
|
9
|
+
## 1) Prioritet pravila
|
|
10
|
+
|
|
11
|
+
- Pre bilo kakve izmene pročitaj bar 80-120 linija fajla koji menjaš.
|
|
12
|
+
- Ako projekat ima linter/formatter/config (`eslint`, `prettier`, `tsconfig`, `editorconfig`, `ruff`, `black`, `gofmt`, itd.), to ima prioritet nad ličnim stilom.
|
|
13
|
+
- Zadrži isti stil uvlačenja koji fajl već koristi (`tab` ili razmaci).
|
|
14
|
+
- Ne radi globalni reformat fajla i ne menjaj linije koje nisu deo zadatka.
|
|
15
|
+
- Ako je stil neujednačen, prati dominantan stil najbližeg koda koji dodaješ.
|
|
16
|
+
|
|
17
|
+
## 2) Kvalitet i organizacija
|
|
18
|
+
|
|
19
|
+
- Kod piši maksimalno profesionalno, organizovano i čitljivo, sa jasnim granicama odgovornosti.
|
|
20
|
+
- Kod obavezno odvajaj u logičke celine praznim redom (deklaracije, validacije, transformacije, side-effect delovi, return).
|
|
21
|
+
- Menjaj minimalan broj linija potreban za zadatak.
|
|
22
|
+
- Ne diraj postojeće whitespace-only razlike van opsega izmene.
|
|
23
|
+
- Ne menjaj formatiranje, whitespace, imenovanje promenljivih i stil postojećih metoda van direktnog opsega zadatka.
|
|
24
|
+
- Ako u postojećem kodu primetiš nejasnoće ili stilsku nekonzistentnost, predloži izmene, ali ih ne primenjuj automatski.
|
|
25
|
+
- Novi kod strukturiraj tako da kasnije dodavanje feature-a i izmene budu jednostavni i bezbedni.
|
|
26
|
+
|
|
27
|
+
## 3) Arhitektura i patterni
|
|
28
|
+
|
|
29
|
+
- Koristi design pattern-e gde imaju smisla (`Singleton`, `Factory`, `Builder`), samo kada realno poboljšavaju čitljivost, testabilnost i proširivost.
|
|
30
|
+
- Pre uvođenja pattern-a proveri da li već postoji isti ili sličan obrazac u projektu i prati taj postojeći pristup.
|
|
31
|
+
- Ne uvodi pattern formalno ako donosi nepotrebnu kompleksnost.
|
|
32
|
+
|
|
33
|
+
## 4) Imenovanje
|
|
34
|
+
|
|
35
|
+
- Poštuj naming konvencije projekta i jezika u kome radiš.
|
|
36
|
+
- Za boolean promenljive nikada ne koristi prefiks `is` (`isValid`, `isActive`, itd.); koristi nazive tipa `valid`, `active`, `enabled`, `exists`.
|
|
37
|
+
|
|
38
|
+
## 5) JS/TS specifično (primeni samo u JS/TS fajlovima)
|
|
39
|
+
|
|
40
|
+
- Koristi `;` na kraju izraza.
|
|
41
|
+
- Preferiraj `'single quotes'` za stringove (osim template stringova).
|
|
42
|
+
- Zadrži postojeći razmak u objektima/nizovima/destrukturiranju ako je tako u fajlu.
|
|
43
|
+
- Uvek koristi `async/await` pattern umesto Promise lanaca (`.then/.catch`) gde god je to moguće i smisleno.
|
|
44
|
+
- Ako fajl koristi `require`, nastavi sa `require` (ne prebacuj na `import` bez jasnog razloga).
|
|
45
|
+
- `import`/`require` izraze grupiši u logičke celine i odvajaj svaku celinu praznim redom.
|
|
46
|
+
- Unutar svake celine sortiraj alfabetski (npr. `AccountController` pre `BookController`).
|
|
47
|
+
- Za React/TS zadrži postojeći obrazac komponenti, hook-ova i tipova koji projekat već koristi.
|
|
48
|
+
- Za sve `public` metode obavezno piši kompletan JSDoc komentar iznad metode.
|
|
49
|
+
- JSDoc za `public` metodu treba da sadrži najmanje: `@public`, `@param` (za svaki parametar), `@returns` (osim kada metoda zaista ništa ne vraća), i `@static` kada je metoda statička.
|
|
50
|
+
- Po potrebi dodaj i ostale relevantne tagove (`@throws`, `@async`, `@deprecated`, `@example`) da dokumentacija bude kompletna i korisna.
|
|
51
|
+
|
|
52
|
+
## 6) Fajlovi i struktura
|
|
53
|
+
|
|
54
|
+
- Novi fajl imenuj po konvenciji foldera/projekta u koji dodaješ.
|
|
55
|
+
- Ne premeštaj fajlove i ne menjaj naming konvenciju bez eksplicitnog zahteva.
|
|
56
|
+
- Ako postoji konflikt stilova između različitih delova repoa, prati stil ciljanog paketa/fajla.
|
|
57
|
+
|
|
58
|
+
## 7) Proaktivni predlozi i approval gate
|
|
59
|
+
|
|
60
|
+
- Ako primetiš bug, potencijalni problem performansi ili efikasnije rešenje, obavezno ga predloži.
|
|
61
|
+
- Svaki predlog napiši jasno: koji deo koda/fajl je problem i zašto je korisno to popraviti (stabilnost, brzina, održavanje, čitljivost).
|
|
62
|
+
- Ako primetiš da postojeći kod ne prati SOLID principe, da je previše kompleksan ili teško razumljiv, obavezno predloži refaktor korake.
|
|
63
|
+
- Za ovakve proaktivne izmene važi approval gate: ne izvršavaj ih automatski, već tek nakon moje eksplicitne potvrde.
|
|
64
|
+
|
|
65
|
+
## 8) Commit poruke (Conventional Commits)
|
|
66
|
+
|
|
67
|
+
- Koristi Conventional Commits standard za commit poruke (npr. `feat: ...`, `fix: ...`, `refactor: ...`, `chore: ...`) i piši predlog poruke profesionalno, jasno i u tom formatu.
|
|
68
|
+
- Kada tražim da napišeš commit message za prethodne izmene, obavezno napiši poruku koja jasno obuhvata šta je sve izmenjeno.
|
|
69
|
+
|
|
70
|
+
## 9) Release notes (`.releases`)
|
|
71
|
+
|
|
72
|
+
- Kada tražim release, obavezno dodaj novi fajl u `.releases` folder koristeći postojeću strukturu release fajlova tog projekta.
|
|
73
|
+
- Release fajl piši u Markdown formatu sa podebljanim sekcijama i listama, u stilu postojećih fajlova (npr. `**Sekcija**` + `* stavka`).
|
|
74
|
+
- Koristi sledeće ključne sekcije kada su primenljive: `**Bug Fixes**`, `**New Features**`, `**Technical Enhancements**`, `**Other**`, `**Configuration Changes**`.
|
package/AGENTS.md
ADDED
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
# Univerzalna pravila pisanja koda (važe za svaki projekat)
|
|
2
|
+
|
|
3
|
+
Piši novi i izmenjeni kod tako da izgleda kao da je pisan u istom stilu kao postojeći kod oko njega.
|
|
4
|
+
|
|
5
|
+
## 1) Prioritet pravila
|
|
6
|
+
|
|
7
|
+
- Pre bilo kakve izmene pročitaj bar 80-120 linija fajla koji menjaš.
|
|
8
|
+
- Ako projekat ima linter/formatter/config (`eslint`, `prettier`, `tsconfig`, `editorconfig`, `ruff`, `black`, `gofmt`, itd.), to ima prioritet nad ličnim stilom.
|
|
9
|
+
- Zadrži isti stil uvlačenja koji fajl već koristi (`tab` ili razmaci).
|
|
10
|
+
- Ne radi globalni reformat fajla i ne menjaj linije koje nisu deo zadatka.
|
|
11
|
+
- Ako je stil neujednačen, prati dominantan stil najbližeg koda koji dodaješ.
|
|
12
|
+
|
|
13
|
+
## 2) Kvalitet i organizacija
|
|
14
|
+
|
|
15
|
+
- Kod piši maksimalno profesionalno, organizovano i čitljivo, sa jasnim granicama odgovornosti.
|
|
16
|
+
- Kod obavezno odvajaj u logičke celine praznim redom (deklaracije, validacije, transformacije, side-effect delovi, return).
|
|
17
|
+
- Menjaj minimalan broj linija potreban za zadatak.
|
|
18
|
+
- Ne diraj postojeće whitespace-only razlike van opsega izmene.
|
|
19
|
+
- Ne menjaj formatiranje, whitespace, imenovanje promenljivih i stil postojećih metoda van direktnog opsega zadatka.
|
|
20
|
+
- Ako u postojećem kodu primetiš nejasnoće ili stilsku nekonzistentnost, predloži izmene, ali ih ne primenjuj automatski.
|
|
21
|
+
- Novi kod strukturiraj tako da kasnije dodavanje feature-a i izmene budu jednostavni i bezbedni.
|
|
22
|
+
|
|
23
|
+
## 3) Arhitektura i patterni
|
|
24
|
+
|
|
25
|
+
- Koristi design pattern-e gde imaju smisla (`Singleton`, `Factory`, `Builder`), samo kada realno poboljšavaju čitljivost, testabilnost i proširivost.
|
|
26
|
+
- Pre uvođenja pattern-a proveri da li već postoji isti ili sličan obrazac u projektu i prati taj postojeći pristup.
|
|
27
|
+
- Ne uvodi pattern formalno ako donosi nepotrebnu kompleksnost.
|
|
28
|
+
|
|
29
|
+
## 4) Imenovanje
|
|
30
|
+
|
|
31
|
+
- Poštuj naming konvencije projekta i jezika u kome radiš.
|
|
32
|
+
- Za boolean promenljive nikada ne koristi prefiks `is` (`isValid`, `isActive`, itd.); koristi nazive tipa `valid`, `active`, `enabled`, `exists`.
|
|
33
|
+
|
|
34
|
+
## 5) JS/TS specifično (primeni samo u JS/TS fajlovima)
|
|
35
|
+
|
|
36
|
+
- Koristi `;` na kraju izraza.
|
|
37
|
+
- Preferiraj `'single quotes'` za stringove (osim template stringova).
|
|
38
|
+
- Zadrži postojeći razmak u objektima/nizovima/destrukturiranju ako je tako u fajlu.
|
|
39
|
+
- Uvek koristi `async/await` pattern umesto Promise lanaca (`.then/.catch`) gde god je to moguće i smisleno.
|
|
40
|
+
- Ako fajl koristi `require`, nastavi sa `require` (ne prebacuj na `import` bez jasnog razloga).
|
|
41
|
+
- `import`/`require` izraze grupiši u logičke celine i odvajaj svaku celinu praznim redom.
|
|
42
|
+
- Unutar svake celine sortiraj alfabetski (npr. `AccountController` pre `BookController`).
|
|
43
|
+
- Za React/TS zadrži postojeći obrazac komponenti, hook-ova i tipova koji projekat već koristi.
|
|
44
|
+
- Za sve `public` metode obavezno piši kompletan JSDoc komentar iznad metode.
|
|
45
|
+
- JSDoc za `public` metodu treba da sadrži najmanje: `@public`, `@param` (za svaki parametar), `@returns` (osim kada metoda zaista ništa ne vraća), i `@static` kada je metoda statička.
|
|
46
|
+
- Po potrebi dodaj i ostale relevantne tagove (`@throws`, `@async`, `@deprecated`, `@example`) da dokumentacija bude kompletna i korisna.
|
|
47
|
+
|
|
48
|
+
## 6) Fajlovi i struktura
|
|
49
|
+
|
|
50
|
+
- Novi fajl imenuj po konvenciji foldera/projekta u koji dodaješ.
|
|
51
|
+
- Ne premeštaj fajlove i ne menjaj naming konvenciju bez eksplicitnog zahteva.
|
|
52
|
+
- Ako postoji konflikt stilova između različitih delova repoa, prati stil ciljanog paketa/fajla.
|
|
53
|
+
|
|
54
|
+
## 7) Proaktivni predlozi i approval gate
|
|
55
|
+
|
|
56
|
+
- Ako primetiš bug, potencijalni problem performansi ili efikasnije rešenje, obavezno ga predloži.
|
|
57
|
+
- Svaki predlog napiši jasno: koji deo koda/fajl je problem i zašto je korisno to popraviti (stabilnost, brzina, održavanje, čitljivost).
|
|
58
|
+
- Ako primetiš da postojeći kod ne prati SOLID principe, da je previše kompleksan ili teško razumljiv, obavezno predloži refaktor korake.
|
|
59
|
+
- Za ovakve proaktivne izmene važi approval gate: ne izvršavaj ih automatski, već tek nakon moje eksplicitne potvrde.
|
|
60
|
+
|
|
61
|
+
## 8) Commit poruke (Conventional Commits)
|
|
62
|
+
|
|
63
|
+
- Koristi Conventional Commits standard za commit poruke (npr. `feat: ...`, `fix: ...`, `refactor: ...`, `chore: ...`) i piši predlog poruke profesionalno, jasno i u tom formatu.
|
|
64
|
+
- Kada tražim da napišeš commit message za prethodne izmene, obavezno napiši poruku koja jasno obuhvata šta je sve izmenjeno.
|
|
65
|
+
|
|
66
|
+
## 9) Release notes (`.releases`)
|
|
67
|
+
|
|
68
|
+
- Kada tražim release, obavezno dodaj novi fajl u `.releases` folder koristeći postojeću strukturu release fajlova tog projekta.
|
|
69
|
+
- Release fajl piši u Markdown formatu sa podebljanim sekcijama i listama, u stilu postojećih fajlova (npr. `**Sekcija**` + `* stavka`).
|
|
70
|
+
- Koristi sledeće ključne sekcije kada su primenljive: `**Bug Fixes**`, `**New Features**`, `**Technical Enhancements**`, `**Other**`, `**Configuration Changes**`.
|
|
@@ -60,16 +60,44 @@ module.exports = (() => {
|
|
|
60
60
|
return Promise.reject(`Instrument lookup for [ ${symbol} ] failed, the instrument does not exist`);
|
|
61
61
|
}
|
|
62
62
|
|
|
63
|
-
|
|
63
|
+
normalizeInstrument(result.instrument);
|
|
64
64
|
|
|
65
|
-
|
|
66
|
-
|
|
65
|
+
return result;
|
|
66
|
+
});
|
|
67
|
+
}
|
|
68
|
+
|
|
69
|
+
/**
|
|
70
|
+
* Returns a promise for metadata for multiple instruments.
|
|
71
|
+
*
|
|
72
|
+
* @public
|
|
73
|
+
* @async
|
|
74
|
+
* @param {String[]} symbols
|
|
75
|
+
* @returns {Promise<Object>}
|
|
76
|
+
*/
|
|
77
|
+
async getInstruments(symbols) {
|
|
78
|
+
assert.argumentIsArray(symbols, 'symbols', String);
|
|
79
|
+
assert.argumentIsValid(symbols.length, 'symbols.length', x => x > 0, 'is greater than zero');
|
|
67
80
|
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
81
|
+
const symbolList = symbols.join(',');
|
|
82
|
+
|
|
83
|
+
return promise.timeout(Gateway.invoke(instrumentsLookupEndpoint, { symbols: symbolList }), this._waitInMilliseconds, 'instrument lookup')
|
|
84
|
+
.catch((e) => {
|
|
85
|
+
let message;
|
|
86
|
+
|
|
87
|
+
if (is.string(e) && e === 'timeout') {
|
|
88
|
+
message = `Instrument lookup for [ ${symbolList} ] failed due to timed out`;
|
|
89
|
+
} else {
|
|
90
|
+
message = `Instrument lookup for [ ${symbolList} ] failed due to an unspecified error`;
|
|
91
|
+
}
|
|
92
|
+
|
|
93
|
+
return Promise.reject(message);
|
|
94
|
+
}).then((result) => {
|
|
95
|
+
if (result.instruments === null) {
|
|
96
|
+
return Promise.reject(`Instrument lookup for [ ${symbolList} ] failed, no instruments were returned`);
|
|
97
|
+
}
|
|
98
|
+
|
|
99
|
+
if (is.array(result.instruments)) {
|
|
100
|
+
result.instruments.forEach(normalizeInstrument);
|
|
73
101
|
}
|
|
74
102
|
|
|
75
103
|
return result;
|
|
@@ -94,5 +122,32 @@ module.exports = (() => {
|
|
|
94
122
|
.withErrorInterceptor(ErrorInterceptor.GENERAL)
|
|
95
123
|
.endpoint;
|
|
96
124
|
|
|
125
|
+
const instrumentsLookupEndpoint = EndpointBuilder.for('query-instruments', 'query instruments')
|
|
126
|
+
.withVerb(VerbType.GET)
|
|
127
|
+
.withProtocol(ProtocolType.HTTPS)
|
|
128
|
+
.withHost('instruments-prod.aws.barchart.com')
|
|
129
|
+
.withPort(443)
|
|
130
|
+
.withPathBuilder((pb) => {
|
|
131
|
+
pb.withLiteralParameter('instruments', 'instruments');
|
|
132
|
+
})
|
|
133
|
+
.withQueryBuilder((qb) => {
|
|
134
|
+
qb.withVariableParameter('symbols', 'symbols', 'symbols');
|
|
135
|
+
})
|
|
136
|
+
.withResponseInterceptor(ResponseInterceptor.DATA)
|
|
137
|
+
.withErrorInterceptor(ErrorInterceptor.GENERAL)
|
|
138
|
+
.endpoint;
|
|
139
|
+
|
|
140
|
+
function normalizeInstrument(instrument) {
|
|
141
|
+
if (instrument && instrument.symbolType === 18) {
|
|
142
|
+
const match = instrument.name.match(regex.crypto.token) || null;
|
|
143
|
+
|
|
144
|
+
if (match !== null) {
|
|
145
|
+
instrument.name = match[1];
|
|
146
|
+
instrument.currency = 'USD';
|
|
147
|
+
instrument.symbolType = 999;
|
|
148
|
+
}
|
|
149
|
+
}
|
|
150
|
+
}
|
|
151
|
+
|
|
97
152
|
return InstrumentProvider;
|
|
98
|
-
})();
|
|
153
|
+
})();
|