Iterator

[nleanba]

Using the new async Iterator SynoGroup Lib

[retog]

I think the code is working because it relies on two different versions of '@factsmission/synogroup'. An older version which exports SynonymGroup as named export which is used by typescript for type-checks and a new version which is used at runtime. As the import resolved by the browser is js without types and webpack probably acts after typescript anyway, this cannot be used for types.

I think we have the following option:

• re-create the node version of syno-group. As the es module cannot be used by webpack we would still be using the hack with the global variable and the external in webpack. Furthermore, this probably cannot be achieved nicely in the synogroup code, i.e. without duplicated and generated content as well as redundant configurations for npm/deno/tsc as this was the case in https://github.com/factsmission/synogroup/tree/fa0a58a0e501d07e117e3df2bba20d3321bf4c40.
• Ignore the types (use any type or use js)
• Use https://vno.land/ - I don't see any disadvantage in this approach. Sure it takes a couple of hours to migrate, but compare this with the time spent struggling with webpack, npm and babel issues.

[nleanba]

I think the code is working because it relies on two different versions of '@factsmission/synogroup'. An older version which exports SynonymGroup as named export which is used by typescript for type-checks and a new version which is used at runtime. As the import resolved by the browser is js without types and webpack probably acts after typescript anyway, this cannot be used for types.

There's absolutely no requirement for the two library versions to be out of sync - but as you've stopped publishing npm packages, which seemed to be the easiest way to consume the typings, and as there have not been any breaking changes - the current configuration works.

I think we have the following option:

• re-create the node version of syno-group. As the es module cannot be used by webpack we would still be using the hack with the global variable and the external in webpack. Furthermore, this probably cannot be achieved nicely in the synogroup code, i.e. without duplicated and generated content as well as redundant configurations for npm/deno/tsc as this was the case in https://github.com/factsmission/synogroup/tree/fa0a58a0e501d07e117e3df2bba20d3321bf4c40.

This should be relatively easy to do, and it's unclear to me what you mean by duplicated content?

At that point in time we had three generated code files: index.js, made by deno; index.d.ts, made by tsc; and a map for the latter, which probably was pointless and is easily removed from the tsc config. The two files neccesary for this aproach have very little (unnecessary) overlap.

• Ignore the types (use any type or use js)

This would make the use of TypeScript pointless & I don't see any reasons to revert to untyped JS.

• Use https://vno.land/ - I don't see any disadvantage in this approach. Sure it takes a couple of hours to migrate, but compare this with the time spent struggling with webpack, npm and babel issues.

I'd prefer to discuss and handle a potential move to vno at a later point and not mix it with functionality updates. Currently, our focus should be on replacing the classic view with what is now (still) the beta which would open many opportunities for optimization, as now there are a couple of shared components which thus require additional complexity or "adapters" to handle both pages.

This leaves the first option.

I would thus suggest the following next steps:

1. consolidating (your) changes in SynoGroup into a final npm release (maybe even types only?)
2. Implementing the requested/required code changes
   → here's where this PR would get merged
3. Getting the Beta up to speed (See Issue #61)
4. Remove the older classic view
5. Remove unneccesary complexity in previously shared components
6. ... then discuss / make changes in the general architecture, such as moving to JS and/or vno.
   I believe that these changes should be as easy, maybe even easier due to the achieved uniformity (compared to the current mix of mostly vue components, some JS utilities, JS "components", and TS utilities → by then, this should be reduced to vue components and TS utilities), to implement then as they are now.

[retog]

I think the code is working because it relies on two different versions of '@factsmission/synogroup'. An older version which exports SynonymGroup as named export which is used by typescript for type-checks and a new version which is used at runtime. As the import resolved by the browser is js without types and webpack probably acts after typescript anyway, this cannot be used for types.

There's absolutely no requirement for the two library versions to be out of sync - but as you've stopped publishing npm packages, which seemed to be the easiest way to consume the typings, and as there have not been any breaking changes - the current configuration works.

There was never documented code to generate type declarations from the code, there was just a directory with some generated code in git, which is not as we do things.

I think we have the following option:

• re-create the node version of syno-group. As the es module cannot be used by webpack we would still be using the hack with the global variable and the external in webpack. Furthermore, this probably cannot be achieved nicely in the synogroup code, i.e. without duplicated and generated content as well as redundant configurations for npm/deno/tsc as this was the case in https://github.com/factsmission/synogroup/tree/fa0a58a0e501d07e117e3df2bba20d3321bf4c40.

This should be relatively easy to do, and it's unclear to me what you mean by duplicated content?

all that is in https://github.com/factsmission/synogroup/tree/fa0a58a0e501d07e117e3df2bba20d3321bf4c40/package seems to b redundat with the content of the superfolder

At that point in time we had three generated code files: index.js, made by deno; index.d.ts, made by tsc; and a map for the latter, which probably was pointless and is easily removed from the tsc config. The two files neccesary for this aproach have very little (unnecessary) overlap.

type typing is already in the s file, and then there's that sourcemap.

• Ignore the types (use any type or use js)

This would make the use of TypeScript pointless & I don't see any reasons to revert to untyped JS.

• Use https://vno.land/ - I don't see any disadvantage in this approach. Sure it takes a couple of hours to migrate, but compare this with the time spent struggling with webpack, npm and babel issues.

I'd prefer to discuss and handle a potential move to vno at a later point and not mix it with functionality updates. Currently, our focus should be on replacing the classic view with what is now (still) the beta which would open many opportunities for optimization, as now there are a couple of shared components which thus require additional complexity or "adapters" to handle both pages.
The things is, the functionally isn't there. We weren't able to get the module from npmjs.org. The approach presented in this PR is a hack, even if the rutime and the buildtime library distribution are synced to the same version.

This leaves the first option.

The move to vno 9take maybe an hour or two, compare this with all the frustrated commit messages from getting things to work with webpack

I would thus suggest the following next steps:

1. consolidating (your) changes in SynoGroup into a final npm release (maybe even types only?)

2. Implementing the requested/required code changes
   → here's where this PR would get merged

3. Getting the Beta up to speed (See Issue [#61](https://github.com/factsmission/synospecies/issues/61))

4. Remove the older classic view

5. Remove unneccesary complexity in previously shared components

6. ... then discuss / make changes in the general architecture, such as moving to JS and/or vno.
   I believe that these changes should be as easy, maybe even easier due to the achieved uniformity (compared to the current mix of mostly vue components, some JS utilities, JS "components", and TS utilities → by then, this should be reduced to vue components and TS utilities), to implement then as they are now.

we have a working library, we have a working example only this consumer with its vue/npm/webpack/babel dependencies seems to have problems. Nobody suggested moving to JS, just if your platform doesn't work correctly with types then not using them is an approach to get things working quickly without the hack of using both an es-module distributed via HTTP and an npm package.

[retog]

Creating a mode module (separate .d.ts files etc.) from a deno project seems to be a hard thing to do: denoland/deno#4528

Implemented requested changes