Open brprice opened 1 year ago
I think there's nothing we can do about the lodash
warnings, as those are coming from a dependency.
Regarding the import.meta
warning: I think this warning is simply invalid. baseURL
is being set correctly both in development (locally) and in production. I've been aware of this one for awhile and I still don't understand why it's complaining.
I understand where the first (in the OP's ordering) batch of messages come from, and have some idea of how "important" they are. These ones are of the form
Message : ...
Path : ...
Orval seems to call ibm-openapi-validator, which is (surprise!) a validator for openapi specs, written by IBM. By default this validator is stricter than the official spec (it checks against their in-house conventions). In particular, I believe all the snake case
errors are not errors per the spec, but only differ from IBM's conventions.
For some more info, see https://github.com/IBM/openapi-validator/issues/173 https://github.com/IBM/openapi-validator/pull/41 https://github.com/IBM/openapi-validator/blob/main/docs/ibm-cloud-rules.md#customization
Note that orval
uses ibm-openapi-validator
^0.88.0
(in particular, we currently lock it at 0.88.3
: https://github.com/hackworthltd/primer-app/blob/3bb7547f315c402d8a9b13df57ef570fd18f23e4/pnpm-lock.yaml#L14164.
One useful trick is to add "ibm-openapi-validator" : "^0.88.0"
to devDependencies
in package.json
and directly run the underlying linter in verbose mode lint-openapi -v primer-api.json
which will then say what rule is being fired.
These rules are defined in https://github.com/IBM/openapi-validator/tree/main/packages/ruleset
pnpm
has support for overriding dependencies, as well, so we could also pin it to the latest version that I think you had earlier said might handle these better, or something?
pnpm
has support for overriding dependencies, as well, so we could also pin it to the latest version that I think you had earlier said might handle these better, or something?
I think I was confused when I said that. I don't currently think a newer version would make any difference here.
GET .../sessions
(iiuc, a GET
which ends in a literal segment), ibm would like the operation id to be listSessions
rather than getSessionList
.PUT .../{sessionId}/name
has a request body of type string
, and POST .../copy-session
has one of type $ref: UUID
, i.e. string
. Despite the use of "MUST", the spec explictly has an example of this sort.UUID
type/schema has no description
. Presumably this will be generated from metadata attached to the backend's UUID
typePaginatedMeta
has a totalItems
property. We don't give this a description (presumably in the backend's servant type) -- partly due to laziness on our part, partly due it being somewhat self-explanatory. Some of these probably are less obvious and could do with extra metadata. I guess for hygiene (and to catch new cases) it may be good to add descriptions to everythingAs far as I know, none of these are problems according to the openapi spec, but only for ibm's sense of taste.
There are a few general categories that make up most the warnings here:
I suggest we deal with these and then have another think about the miscellaneous other ones.
Many of those sound warnings sound like reasonable changes to make. I suppose we can think of these as linting. But it's not a high priority, in any case.
When entering a
nix develop
shell (or manually usingpnpm generate
), there are lots of messages printed of the formIt appears that many of these are printed twice, once as a warning and once as an error. All the warnings are in one batch, followed by all the errors.
Note that there are a few different sorts of errors, and many messages are printed. As a simple summary I ran
nix28 develop -c 'true' > /tmp/msgs 2>&1
and found 503 lines (though a few are from nix, and not all are warnings etc). The unique messages (ignoring thePath
lines) areAnd the worrying lines not of this form are
and
It is not clear how many of these indicate actual problems (e.g. in our openapi spec). Nor is it clear how many root causes there are. As we understand more it may be sensible to split this issue up. For now, I will use this issue to record my current understanding.