Hacktoberfest: Creating d.ts files for neo classes

i can help here if this is still open ?

ive looked into this problem a little and since the jsautodoc annotations have been followed we can generate the files however a lot of the files have incorrect annotations and as such we would first need to correct them @tobiu example of one such incorrect ts i found amongst others

i adjusted the mentioned file. kind of obvious that an async method needs a Promise return value comment. @returns {Promise<Object>} in this case.

feel free to open tickets for other spots you find. easy PRs.

at the start of the project, i went for uppercase Boolean, Number, String inside type comments. in retrospective using the lowercase versions would have been cleaner. i would hold off on this one for the current code base (too many spots), but it makes sense to do it properly inside the new d.ts files right from the start.

the real deal why we can not use auto-generator scripts but need AI (or a highly customised own script) is the class config system:

take a close look at: https://github.com/neomjs/neo/commit/ee3f7b16ab542a200ce88af6b8ae647a366da8f6

everything inside static config will get added to the class prototype (get / set driven) and configs for class extensions will get merged.

on top, every config which ends with an underscore enables us to optionally use hooks.

example: a button has a text_ config which optionally allows us to use beforeGetText(value), beforeSetText(value, oldValue), afterSetText(value, oldValue).

the hooks do not necessarily need to get into the d.ts definitions (would be a nice goodie on top), but getting the configs right is crucial.

the mentioned AI commit does it well to some degree (just for 3 files).

i see what youre getting at with reference to commit i would also like to point out that the ai generated should be the default but the generator does work for smaller isolated modules also i would like suggest a change wherein all d.ts files are in a separate types folder as is the standard in various repositiories to prevent the codebase from getting cluttered the new fs being similar to this

in case you want to understand the config system (it is super nice), i created some blog posts about it.

code wise: https://github.com/neomjs/neo/blob/dev/src/Neo.mjs#L417 https://github.com/neomjs/neo/blob/dev/src/core/Base.mjs#L498

regarding the folder structure: if we are doing this with the d.ts files, my idea was to convert current class files into folders.

e.g. src/button/Base.mjs

src/button/base containing: Base.d.ts Base.mjs Base.scss // css structure, theme files need to stay separate Base.stories.mjs // Storybook Base.test.mjs // Siesta tests

this would need changes for the build scripts as well as the internal class name to file mappings.

just to clarify the types file go in the same place as a the mjs files otherwise we'd need a rehaul of the whole system ?

@tobiu if yes could you check out #6017 and offer input ? cuz it'd help to know if i need to put the file in the same dir for keeping the fs consistent

getting started with a type top-level folder which mimics the structure of the src folder is fine for me.

just one big wish: let us stick to the following branch for now: https://github.com/neomjs/neo/tree/d.ts-files

rationale: while we can work inside the types folder in isolation, at some point we need to modify the src files to import the new d.ts files inside comments. when we get to a PoC state where auto completion for configs works properly inside IDEs, then I would rebase the feature branch into dev.

also take a look at: https://github.com/neomjs/neo/blob/d.ts-files/src/util/KeyNavigation.d.ts#L18

the import in line1 should fetch the d.ts file (a .js file does not even exist).

i am not a TS pro (not even close), but i guess the AI concept of creating a Config interface which extends the base class interface does make sense.

several open questions, like if declare namespace Neo.util { when used multiple times (files inside the util folder) would merge the TS namespace or overwrite it.

Since the event has ended, i will close all hacktoberfest related tickets now. In case someone still wants to work on a related ticket, feel free to add a comment and we can reopen it.