search

Apicurio / apicurio-editors

React based editors for OpenAPI and AsyncAPI.
Apache License 2.0
2 stars 2 forks source link

initial project configuration #4

Closed tplevko closed 2 months ago

tplevko commented 2 months ago

initial project configuration with vite, react, patternfly and storybook

added also two basic modals with stories for Add Path and Add Tag

EricWittmann commented 2 months ago

Why use yarn instead of npm? Any issues with productization doing that?

EricWittmann commented 2 months ago

Also can we apply Apicurio code styling if there are no objections (expecting there might be)?

Also we might want to rename vite-config.ts to vite-config.mts if we plan to use vite-tsconfig-paths. I had to do this recently:

lordrip commented 2 months ago

Why use yarn instead of npm? Any issues with productization doing that?

@EricWittmann , nothing in terms of productization, mostly because handling multiple modules in a monorepo fashion is easier with yarn than npm. In the case of npm, we would need to use lerna or nx in order to orchestrate multiple modules and their dependencies.

yarn 1.x vs 4.x is mostly because 1.x is deprecated.

That being said, I'm not against using npm, it's just a bit more work and that's it.

Please let us know what your preference is so we can "choose our destiny" :smile:

lordrip commented 2 months ago

Also can we apply Apicurio code styling if there are no objections (expecting there might be)?

We could, we just need to pick one of the following scenarios:

  1. Upgrade apicurio-registry eslint config to be compatible with eslint 9.x, since they changed the configuration file format
  2. Downgrade eslint in this project to 8.x in order to be compatible

Also we might want to rename vite-config.ts to vite-config.mts if we plan to use vite-tsconfig-paths.

Sure, we can. I'm not sure we're gonna use vite-tsconfig-paths at this point, but better to accommodate this scenario just in case

EricWittmann commented 2 months ago

Why use yarn instead of npm? Any issues with productization doing that?

@EricWittmann , nothing in terms of productization, mostly because handling multiple modules in a monorepo fashion is easier with yarn than npm. In the case of npm, we would need to use lerna or nx in order to orchestrate multiple modules and their dependencies.

yarn 1.x vs 4.x is mostly because 1.x is deprecated.

That being said, I'm not against using npm, it's just a bit more work and that's it.

Please let us know what your preference is so we can "choose our destiny" 😄

Great thanks! I have no preference, I was just curious. Will this project utilize multiple modules?

(agree that multi-module with npm is terrible, I didn't know that yarn did it better)

EricWittmann commented 2 months ago

Also can we apply Apicurio code styling if there are no objections (expecting there might be)?

We could, we just need to pick one of the following scenarios:

1. Upgrade apicurio-registry eslint config to be compatible with `eslint 9.x`, since they changed the configuration file format

2. Downgrade `eslint` in this project to `8.x` in order to be compatible

Yeah let's upgrade apicurio's eslint config! I've been holding back on upgrading to eslint 9.x in other projects because I haven't had time to do that. If you know how, or can tell me how, then let's get that done! Would be a nice improvement.

lordrip commented 2 months ago

@EricWittmann

Great thanks! I have no preference, I was just curious. Will this project utilize multiple modules? (agree that multi-module with npm is terrible, I didn't know that yarn did it better)

I think it would be convenient to have at least 2 modules, similar to what we have in Kaoto: a. The main module exporting components b. A testing module that imports the public components and adds stories and e2e.

There are a couple of advantages with the latter: a. In case of security vulnerabilities, they will be properly reflected on the right package, for instance, if there's an issue with a test dependency, it will be reflected on this package, reducing the noise a bit. b. We ensure that we export the right components and that also we keep the API stable, or said in a different way, if there's a breaking change in a component, this module will act as a close consumer, properly identifying when such unintended change happens.

But as I said, this is just a suggestion :smile:

Yeah let's upgrade apicurio's eslint config! I've been holding back on upgrading to eslint 9.x in other projects because I haven't had time to do that. If you know how, or can tell me how, then let's get that done! Would be a nice improvement.

Hehe, me too, I haven't dedicated the time to update Kaoto either :sweat_smile:, I hope that I can take care this week

EricWittmann commented 2 months ago

LGTM