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

Parse and modify top-level declarations in a module #68

Open
1 task done
Lms24 opened this issue Jul 26, 2023 · 1 comment
Open
1 task done

Parse and modify top-level declarations in a module #68

Lms24 opened this issue Jul 26, 2023 · 1 comment

Comments

@Lms24
Copy link
Contributor

Lms24 commented Jul 26, 2023

Describe the feature

I'd like to be able to modify top-level declarations within a module to, for example, modify objects that are exported in a separate statement. Something like:

// currently, there's no magicast-native way of accessing this declaration
const myConfig = defineConfig({/*...*/})
export default myConfig;

I'm using magicast in a script that's supposed to modify a user's vite.config.js and this quite common way of specifying a vite config unfortunately causes problems.

API proposal:

I'm thinking about something along these lines:

const originalCode = `
  const myConfig = defineConfig({/*...*/})
  export default myConfig;
`

const mod = parseModule(originalCode);

// example modification
mod.$declarations.myConfig = builders.raw(...)

Once we have a way of accessing/modifying declarations, we could for example adjust theaddVitePlugin helper to use the $declarations field to adjust the config object if it is not directly default-exported.

I'm happy to give this a try to implement but I'd like to hear your thoughts around this first.

This is somewhat related to #45 but I believe modifying/parsing existing declarations isn't discussed in this issue.

Limitations

I think we need to accept that we couldn't possibly handle all kinds of declarations or complex syntax within them but for starters, I believe handling object declarations or function calls (like defineConfig) might be enough.

Additional information

  • Would you be willing to help implement this feature?
@Lms24
Copy link
Contributor Author

Lms24 commented Jul 27, 2023

An alternative would be to directly link to the actual declaration in the mod.exports.default property. While more convenient, I'd argue it's quite a diversion from representing an AST data structure. Also not sure which of the two options would be easier to implement

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

No branches or pull requests

1 participant