Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reload Interval Feature #52

Closed

Conversation

vrochamaia
Copy link

@vrochamaia vrochamaia commented Jan 19, 2024

The goal of these changes is to support reload intervals for config-dug. The main ideas are:

  • Allow config-dug to support a default and minimum reload intervals.
  • Based on those intervals AND the ones provided by plugins, figure out the shortest one and make the lib reload all the configs.

@vrochamaia vrochamaia changed the base branch from reload-interval-feature to master January 21, 2024 03:54
@@ -3,6 +3,7 @@
"version": "1.0.0-alpha.0",
"author": "Neo Financial Engineering <[email protected]>",
"license": "MIT",
"type": "module",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could have sworn that I committed this change

}
}

setTimeout(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good but it seems like it should exist on the top level object, not in the loadPlugins function

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I added here was because I didn't want to loop through the this.options.plugins array again in that top level function to get the shortest reload interval for plugins. Maybe I can return from the loadPlugins function the configs and also the shortest reload interval to be used on the main loadConfig function.

@@ -4,5 +4,8 @@
"swc": true,
"esm": true
},
"compilerOptions": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure this part is needed? I don't remember having to do this when I added type: module in the secrets manager plugin.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without that, I get this error

Screenshot 2024-01-26 at 9 41 23 AM

I think the reason is because the @tsconfig/node18 which we are extending from has this compilerOptions configuration

"compilerOptions": {
    "lib": ["es2022"],
    "module": "commonjs", <--- Maybe this config here is the culprit? 
    "target": "es2022",

    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "moduleResolution": "node"
  }

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The /example/script-esm-ts is actually with the same problem. If I don't change the tsconfig file I get that same error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants